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ABSTRACT 



A software version management system, also called 
system modeller, provides for automatically collecting 
and recompiling updated versions of component soft- 
ware objects comprising a software program for opera- 
tion on a plurality of personal computers coupled to- 
gether in a distributed software environment via a local 
area network. The component software objects include 
the source and binary files for the software program, 
which stored in various different local and remote stor- 
age means through the environment. The component 
software objects are periodically updated, via a system 
editor, by various users at their personal computers and 
then stored in designated storage means. The manage- 
ment system includes models which are also objects. 
Each of the models is representative of the source ver- 
sions of a particular component software object and 
contain object pointers including a unique name of the 
object, a unique identifier descriptive of the cronologi- 
cal updating of its current version, information as to an 
object's dependencies on other objects and a pathname 
representative of the residence storage means of the 
object. Means are provided in the system editor to no- 
tify the management system when any one of the ob- 
jects is being edited by a user and the management 
system is responsive to such notification to track the 
edited objects and alter their respective models to the 
current version thereof 
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Client: PROGRAM IMPORTS Sqrtint = { 
r ♦■ Sqrtint. Sqrt[3.0]; 
}■ 






















Implementor: PROGRAM EXPORTS Sqrtint ={ 




Sqrt: PUBLIC PROC[s: REAL]RETURN[REAL]={ 
..code to compute sqrt of a number 
}: 
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SqrtInt:DEFINITIONS = { 

Sqrt: PROC[REAL]RETURNS[REAL] ; 
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Btree.model!(Jan 14, 1983, 14:44:11) 

LET@[lndigo]<Cedar>CedaWns/aces,moo(e/!{July 25, 1982, 14:03:03)IN 
LET/nsfa/ices~@[lndigo]<Cedar>Cedar /ns(an(Jes.mode/!(July 25, 1982, 14!lO:12)IN 

Brfee:INTERFACE6rree~@[lvy]<Schmidt>e7ree.cedar!(Sept 9,1982, 13:52:55) 

[Ascii], 

BTreelnst: 87ree~@[lvy]<Schmidt>87ree/mpUea'ar!(Jan 14, 1963, 14:44:09) 
'[] [Instances.Rope. Instances. 10, Instances. Space] ] ] 

Cedarlnterfaces.model!(July, 25, 1982, 14:03:03) 

[ 

/\sc//:INTERFACE~@(lndigo]<Cedar>y4sci;.cedar!(Jjly 10, 1982. 12;25:00)[], 

flope:INTERFACE~@[lndigo]<Cedar>ftope.cetfa/-!(July 10, 1982, 17:00:00)*0, 
/0:INTERFACE~@[lndigo]<Cedar>IO.cedar!(July 12, 1982, 11:00:00)'[], 
Space:INTERFACE-@[lndigo]<Cedar>Space.Ceda/-!(June 10, 1982, 8:35:00)'[] ] 

Cedarlnstances.model!(July25, 1982, 14:10:12) 

[Ascii, Rope, 10, Space]- 

LEl@Cedarlnterface.model\{My 25, 1982, 14:03:03) IN [ 

@[lndigo]<Cedar>>5sc(i7mp/.cedar!(July 10, 1982, 12:30:00)[] [], 
@[lndigo]<Cedat>flope/mp/,cedaf!(July 10, 1982, 17:10:24)*[]' [], 
@[lndigo]<CedarWO/mp;.cec*ar!(July20, 1982, 13:03:03)'[]-[], 
@[lndigo]<Cedar>Space.cedar!(June 11,1 982, 1 5:00:00) •[]' [] ] 
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Cedar Modeller, started on 3-Feb-83 16:16:01 PST 



StartModelBegin Continue StoreBack Unload StopModel 
MakeModRlBcd Bind NewModeller 
Compile Load Start 



ModelName: Example, Model 



Compiling: ExamplelmplA.Mesa 
Compiling: ExamplelmplB.Mesa 



no errors 



StarModel Example .Model 
Prasing Example. Model 
Analyzing Parameters 

Noticed new version of ExamplelmplA.Mesa 



Noticed new version of ExamplelmplB.Mesa 



Begin Example. Model 
Try for compilation: 

ExamplelmplA.MesarConf irm Compilation ? Yes 
Compilation completed, no errors. 

ExamplelmplB.Mesa: Confirm Compilation ? Yes 
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Found 
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Found 
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Enumerate [Ivy]<Schmitd> looking for 
X.Bcd of 1ABCD2346DED 



Found 



Not found 



Enter in version map 



Compile X.Mesa with no parameters 



Enter X.Bcd of 1ABCD2346DED 
in projection table 
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Release Tool: Phase Move 



[Ivy]<Schmidt>X.Mesa!4 
[Ivy]<Schmidt>XImpl .Mesaie 
[Ivy]<Schmidt>Y.Mesa!43 
[Ivy]<Schmidt>YImpl .Mesal34 




[Indigo]<Cedar>X.MesaI2 
[Indigo]<Cedar>XImpl .Mesal3 
[Ind1go]<Cedar>Y.Mesatl 
[Indigo]<Cedar>YImpl .Mesal2 
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Release Tool: Phase Build 



[Ivy]<Schniidt>X.Bcd[23 
CIvy]<Schmidt>XImpl.Bcdl22 
[Ivy3<Schmidt>Y.Bcdll6 
[Ivy]<Schmidt>YInipl .BcdIlZ 




[Indigo]<Cedar>X.Bcdl2 
[Indigo]<Cedar>XImpl.Bcdll 
[Indigo3<Cedar>Y.Bcdll 
[Indigo]<Cedar>YImpl .Bed! 2 
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File Location 


X.Mesa of July 25,1982 14:03:02 
Xlmpl.Mesa of July 25.1982 14:05:06 
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X.Bcd of 1ABCD2346DED 
Xlmpl.Bcd of 2ADEF346EDCA 
Y.Bcd of 3421ABD4235A 
YImpl.Bcd of 23455BBDC63B 


[Indigo]<Cedar>X.Mesa!2 
[Indigo]<Cedar>XImpl .MesaI3 
[Indigo]<Cedar>Y.MesaIl 
[Indigo]<Cedar>YImpl.Mesa!2 
[Indigo]<Cedar>X.Bcdl2 
[Indigo]<Cedar>XImpl .Bcdil 
[Indigo]<Cedar>Y.Bcdll 
[Indigo]<Cedar>YImpl.Bcdl2 
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SOFTWARE VERSION MANAGEMENT SYSTEM 

BACKGROUND OF THE INVENTION 

This invention relates to software version manage- 
ment system and method for handling and maintaining 
software, e.g. software updating uniformily across the 
system, particularly in a large software development 
environment having a group of users or programmers. 
The system is also referred to as the "System Mo- 
deller". 

Programs consisting of a large number of modules 
need to be managed. When the number of modules 
making up a software environment and system exceeds 
some small, manageable set, a programmer cannot be 
sure that every new version of each module in his pro- 
gram will be handled correctly. After each version is 
created, it must be compiled and loaded. In a distributed 
computing environment, files containing the source text 
of a module can be stored in many places in a distributed 
system. The programmer may have to save it some- 
where so others may use it. Without some automatic 
tool to help, the programmer cannot be sure that ver- 
sions of software being transferred to another user or 
programmer are the versions intended to be used. 

A programmer unfamiliar with the composition of 
the program is more likely to make mistakes when a 
simple change is made. Giving this new programmer a 
list of the files involved is not sufficient, since he needs 
to know where they are stored and which versions are 
needed. A tool to verify a list of files, locations and 
correct versions would help to allow the program to be 
built correctly and accurately. A program can be so 
large that simply verifying a description is not suffi- 
cient, since the description of the program is so large 
that it is impractical to maintain it by hand. 

The confusion of a single programmer becomes much 
worse, and the cost of mistakes much higher, when 
many programmers collaborate on a software project. 
In muiti-pwrson projects, changes to one part of a soft- 
ware system can have far-reaching effects. There is 
often confusion about the number of modules affected 
and how to rebuild affected pieces. For example, user- 
visible changes to heavily-used parts of an operating 
system are made very seldom and only at great cost, 
since other programs that depend on the old version of 
the operating system have to be changed to use the 
newer version. To change these programs, the "cor- 
rect" versions of each have to be found, each has to be 
modified, tested, and the new versions installed with the 
new operating system. Changes of this type often have 
to be made quickly because the new system may be 
useless until all components have been converted. Mem- 
bers or users of large software projects are unlikely to 
make such changes without some automatic support. 

The software management problems faced by a pro- 
grammer when he is developing software are made 
worse by the size of the software, the number of refer- 
ences to modules that must agree in version, and the 
need for explicit file movement between computers. 
For example, a programming environment and system 
used at the Palo Alto Research Center of Xerox Corpo- 
ration at Palo Alto, Calif, called "Cedar" now has 
approximately 447,000 lines of Cedar code, and approx- 
imately 2000 source and 2000 object files. Almost all 
binary or object files refer to other binary or object files 
by explicit version stamp. A program will not run until 
all references to an binary or object file refer to the 
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same version of that file. Cedar is too large to store all 
Cedar software on the file system of each programmer's 
machine, so each Cedar programmer has to explicitly 
retrieve the versions he needs to run his system from 
remote storage facilities or file servers. 

Thus, the problem falls in the realm of "Program- 
ming-the-Large" wherein the unit of discourses the 
software module, instead of "Programming-in-the- 
Small", where units include scalor variables, statements, 
expressions and the like. See the Article of Frank 
DeRemer and H. Kron, "Programming-in-the-Large 
versus Programming in the small", IEEE Transactions 
on Software Engineering, Vol. 2(2), pp. 80-86, June 1976. 

To provide solutions solving these problems over- 
viewed above, consider the following: 

1. Languages are provided in which the user can 
describe his system. 

2. Tools are provided for the individual programmer 
that automate management of versions of his programs. 
These tools are used to acquire the desired versions of 
files, automatically recompile and load aprogram, save 
new versions of software for others to use, and provide 
useful information for other program analysis tools such 
as cross-reference programs. 

3. In a large programming project, software is 
grouped together as a release when the versions are all 
compatible and the programs in the release run cor- 
rectly. The languages and tools for the individual pro- 
grammer are extended to include information about 
cross-package dependencies. The release process is 
designed so production of release does not lower the 
productivity of programmers while the release is occur- 
ring. 

To accomplish the foregoing, one must identify the 
kinds of information that must be maintained to describe 
the software systems being developed. The information 
needed can be broken down into three categories: 

1 . File Information: For each version of a system, the 
versions of each file in the system must be specified. 
There must be a way of locating a copy of each version 
in a distributed environment. Because the software is 
always changing, the file information must be change- 
able to reflect new versions as they are created. 

2. Compilation Information: All files needed to com- 
pile the system must be identified. It must be possible to 
compute which files need to be translated or compiled 
or loaded and which are already in machine runnable 
format. This is called "Dependency Analysis." The 
compilation information must also include other param- 
eters of compilation such as compiler switches or flags 
that affect the operation of the compiler when it is run. 

3. Interface Information: In languages that require 
explicit delineation of interconnections between mod- 
ules (e.g. Mesa, Ada), there must be means to express 
these interconnections. 

There has been little research in version control and 
automatic software management. Of that, almost none 
has built on other research in the field. Despite good 
reasons for it, e.g. the many differences between pro- 
gram environments, and the fact that programming 
environments ususally emphasize one or two program- 
ming languages, so the management systems available 
are often closely related to those programming lan- 
guages, this fact reinforces the singularity of this re- 
search. The following is brief review of previous work 
in this area. 

(1) Make Program 
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The Make program, discussed in the Article of Stuart 
J. Feldman, "Make-A Program for Maintaining Com- 
puter Programs", Software Practice & Experience, Vol. 9 
(4), April, 1979, uses a system description called the 
Makefile, which lists an acyclic dependency graph ex- 
plicitly given by the programmer. For each node in the 
dependency graph, the Makefile contains a Make Rule, 
which is to be executed to produce a new version of the 
parent node if any of the son nodes change. 

For example the dependency graph illustrated in 
FIG. 1 shows that xl.o depends on xl.c, and the file 
a.out dep>ends on xl.o and x2.o. The Makefile that rep- 
resents this graph is shown in Table I below. 

TABLE I 
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15 



xl.o 



xl.o 



x2.o 



xl.o 



xl.O: 



x2.o: 



xl.c 



x2.c 



x2.o 



xl.c 



x2.c 



20 



In Table I, the expression, "cc-c xl.c" is the com- 
mand to execute and produce a new version of xl.o 
when xl.c is changed. Make decides to execute the 25 
make rule i.e., compile xl.c, if the file modification time 
of xl.c is newer than that of xl.o. 

The description mechanism shown in Table I is intu- 
itively easy to use and explain. The simple notion of 
dependency, e.g., a file xl.o, that depends on xl.c must 
be recompiled if xl.c is newer, works correctly vitually 
all the time. The Makefile can also be used as a place to 
keep useful commands the programmer might want to 
execute, e.g., 

print: 

pr xl.c x2.c 
defines a name "print" that depends on no other files 
(names). The command "make print" will print the 
source files xl.c and x2.c. There is usually only one 
Makefile per directory, and, by convention, the soft- 
ware in that directory is described by the Makefile. This 
makes it easy to examine unfamiliar directories simply 
by reading the Makefile. 

Make is an extremely fast and versatile tool that has 
become very popular among UNIX users. Unfortu- 
nately, Make uses modification times from the file sys- 
tem to tell which files need to be re-made. Tliese times 
are easily changed by accident and are a very crude 
way of establishing consistency. Often the programmer 
omits some of the dependencies in the dependency 
graph, sometimes by choice. Thus, even if Make em- 
ployed a better algorithm to determine the consistency 
of a system, the Makefile could still omit many impor- 
tant files of a system. 

(2) Source Code Control System (SCCS) 

The Source Code Control System (SCCS) manages 
versions of C source programs enforcing a check-in and 
check-out regimen, controlling access to versions of 
programs being changed. For a description of such 
systems, see the Articles of Alan L. Glasser, "The Evo- 
lution of a Source Code Control System", Proc. Soft- 
ware Quality & Assurance Workshop, Software Engi- 
neering Notes, Vol. 3(5), pp. 122-125, November 1978; 
Evan L. Ivie, "The Programmer's Workbench-A Ma- 
chine for Software Development", Communications of 
the ACM, Vol. 20(10) pp. 746-753, October, 1977; and 
Marc J. Rochkind "The Source Code Control System", 
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IEEE Transactions on Software Engineering, Vol. 1(4), 
pp. 25-34, April 1981. 

A programmer who wants to change a file under 
sees control does so by (1) gaining exclusive access to 
the file by issuing a "get" command, (2) making his 
changes, and (3) saving his changed version as part of 
the SCCS-controUed file by issuing a "delta" command. 
His changes are called a "delta" and are identified by a 
release and level number, e.g., "2.3". Subsequent users 
of this file can obtain a version with or without the 
changes made as part of "delta 2.3". While the program- 
mer has "checked-out" the file, no other programmers 
may store new deltas. Other programmers may obtain 
copies of the file for reading, however. SCCS requires 
that there be only one modification of a file at a time. 
There is much evidence this is a useful restriction in 
multi-person projects. See Glasser, Supra. SCCS stores 
all versions of a file in a special file that has a name 
prefixed by "s.". This "s." file represents these deltas as 
insertions, modifications, and deletions of lines in the 
file. Their representation allows the "get" command to 
be very fast. 

(3) Software Manufacturing Facility (SMF) 

Make and SCCS were unified in special tools for a 
development project at Bell Labs called the Software 
Manufacturing Facility (SMF) and discussed in the 
Article of Eugene Cristofer, F. A. Wendt and B. C. 
Wonsiewicz, "Source Control & Tools = Stable Sys- 
tems", Proceedings of the Fourth Computer Software & 
Applications Conference, pp. 527-532, Oct. 29-31, 1980. 
TTie SMF uses Make and SCCS augmented by special 
files called slists, which list desired versions of files by 
their SCCS version number. 

A slist may refer to other slists as well as files. In the 
SMF, a system consists of a master slist and references 
to a set of slists that describe subsystems. Each subsys- 
tem may in turn describe other subsystems or files that 
are part of the system. The SMF introduces the notion 
of a consistent software system: only one version of a 
file can be present in all slists that are part of the system. 
Part of the process of building a system is checking the 
consistency. 

SMF also requires that each slist refer to at least one 
Makefile. Building a system involves (1) obtaining the 
SCCS versions of each file, as described in each slists, 
(2) performing the consistency check, (3) running the 
Make program on the version of the Makefile listed in 
the slist, and (4) moving files from this slist to an appro- 
priate directory. FIG. 2 shows an example of a hierar- 
chy of slists, where ab.sl is the master slist. 

SMF includes a database of standard versions for 
common files such as the system library. Use of SMF 
solves the problem created when more than one pro- 
grammer is making changes to the software of a system 
and no one knows exactly which files are included in 
the currently executing systems. 

(4) PIE Project 

The PIE project is an extension to Smalltalk devel- 
oped at the Palo Alto Research Center of Xerox Corpo- 
ration and set forth in the Articles of Ira P. Goldstein 
and Daniel G. Bobrow, "A Layered Approach to Soft- 
ware Design", Xerox PARC Technical Report CSL-80-5, 
December 1980; Ira P. Goldstein and Daniel G. Bo- 
brow, "Descriptions for a Programming Environment", 
Proceedings of the First Annual Conference of the Na- 
tional Association of Artificial Intelligence, Stanford, 
Calif, August 1980; Ira P. Goldstein and Daniel G. 
Bobrow, "Representing Design Alternatives", Proceed- 
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ings of the Artificial Intelligence and Simulation of Behav- 
ior Conference, Amsterdam, July 1980; and the book 
"Smalltalk-80, The Language and It Implemention" by 
Adele Goldberg and David Robson and pubUshed by 
Addison-Wesley, 1983. PIE implements a network 5 
database of Smalltalk objects, i.e., data and procedures 
and more powerful display and usage primitives. PIE 
allows users to categorize different versions of a Small- 
talk object into layers, which are typically numbered 
starting at zero. A list of these layers, most-preferred 10 
layer first, is called a context. A context is a search path 
of layers, applied dynamically whenever an object in 
the network database is referenced. Among objects of 
the same name, the one with the layer number that 
occurs first in the context is picked for execution. 15 
Whenever the user wants to switch versions, he or she 
arranges his context so the desired layer occurs before 
any other layers that might apply to his object. The 
user's context is used whenever any object is refer- 
enced. 20 

The distinction of PIE*s solution to the version con- 
trol problem is the ease with which it handles the dis- 
play of and control over versions. PIE inserts objects or 
procedures into a network that corresponds to a tradi- 
tional hierarchy plus the threads of layers through the 25 
network. The links of the network can be traversed in 
any order. As a result, sophisticated analysis tools can 
examine the logically-related procedures that are 
grouped together in what is called a Smalltalk "class". 
More often, a PIE browser is used to move through the 30 
network. The browser displays the "categories", com- 
prising a grouping of classes, in one comer of a display 
window. Selection of a category displays a list of classes 
associated with that category, and so on until a list of 
procedures is displayed. By changing the value of a 35 
field labeled "Contexts:" the user can see a complete 
picture of the system as viewed from each context. This 
interactive browsing features makes comparison of dif- 
ferent versions of software very convenient. 

(5) Gandalf Project 40 

A project, termed the Gandalf project at Carnegie 
Mellon University, and discussed in the Article of A. 
Nico Habermann et al., "The Second Compendium of 
Gandalf Documention", CMU Department of Com- 
puter Science, May 1980, is implementing parts of an 45 
integrated software development environment for the 
GC language, an extension of the C language. Included 
are a syntax-directed editor, a configuration database, 
and a language for describing what is called system 
compositions. See the Articles of A. Nico Haberman 50 
and Dewayne E. Perry "System Compositions and 
Version Control for Ada", CMU Computer Science 
Department, May 1980 and A. Nico Haberman "Tools 
for Software System Construction", Proceedings of the 
Software Took Workshop, Boulder. Colo.. May 1979. 55 
Various Ph.D these have explored this language for 
system composition. See the Ph.D Thesis of Lee W. 
Cooprider "The Representation of Families of Software 
Systems", CMU Computer Science Department, CMU- 
CS-79-116, Apr. 14, 1979 and Walter F. Tichy, "Soft- 60 
ware Development Control Based on System Structure 
Description", CMU Computer Science Department, 
CMU-CS-80-120, January 1980. 

Recent work on a System Version Control Environ- 
ment (SVCE) combines Gandalf s system composition 65 
language with version control over multiple versions of 
the same component, as explained in the Article of Gail 
E. kaiser and A. Nico Habenn^nn, "An Environment 



for System Version Control", in "The Second Compen- 
dium of Gandalf Documentation", CMU Department 
of Computer Science, Feb. 4, 1982. Parallel versions, 
which are different implementations of the same specifi- 
cation, can be specified using the name of the specific 
version. There may be serial versions of each compo- 
nent which are organized in a time-dependent manner. 
One of the serial versions, called a revision, may be 
referenced using an explicit time stamp. One of these 
revisions is designated as the "standard" version that is 
used when no version is specified. 

Descriptions in the System Version Control Lan- 
guage (SVCL) specify which module versions and revi- 
sions to use and is illustrated, in part, in FIG. 3. A col- 
lection of logically-related software modules is de- 
scribed by a box that names the versions and revisions 
of modules available. Boxes can include other boxes or 
modules. A module lists each parallel version and revi- 
sion available. Other boxes or modules may refer to 
each version using postfix qualifiers on module names. 
For example, "M" denotes the standard version of the 
module whose name is "M," and "M.Vl" denote paral- 
lel version VI. Each serial revision can be specified 
with an "@," e.g., "M.V1@2" for revision 2. 

Each of these expressions, called pathnames, identi- 
fies a specific parallel version and revision. Pathnames 
behave like those in the UNIX system: a path name that 
begins, for example, /A/B/C refers to box C contained 
in box B contained in A. Pathnames without a leading 
"/" are relative to the current module. Implementations 
can be used to specify the modules of a system, and 
compositions can be used to group implementations 
together and to specify which module to use when 
several modules provide the same facilities. These ways 
of specifying and grouping versions and revisions alloy 
virtually any level of binding: the user may choose 
standard versions or, if it is important, the user can be 
very specific about versions desired. The resulting sys- 
tem can be modified by use of components that special- 
ize versions for any particular application as illustrated 
in FIG. 3. 

SVCE also contains facilities for "System Genera- 
tion". The Gandalf environment provides a command 
to make a new instantiation, or executable system, for 
an implementation or composition. This command com- 
piles, links, and loads the constituent modules. The 
Gandalf editor is used to edit modules and edit SVCL 
implementations directly, and the command to build a 
new instantiation is given while using the Gandalf edi- 
tor. Since the editor has built-in templates for valid 
SVCL constructs, entering new implementations and 
compositions is very easy. 

SVCE combines system descriptions with version 
control, coordinated with a database of programs. Of 
the existing systems, this system comes closest to ful- 
fillng the three previously mentioned requirements: 
Their file information is in the database, their recompi- 
lation information is represented as lines in the database 
between programs and their interface information is 
represented by system compositions. 

(6) Intermetrics Approach 

A system used to maintain a program of over one 
million lines of Pascal code is described in an Article of 
Arra Avakian et al, "The Design of an Integrated Sup- 
port Software System", Proceedings of the SIGPLAN '82 
Syposium on Compiler Construction, pp. 308-317, June 
23-25, 1982. The program is composed of 1500 sepa- 
rately-compiled components developed by over 200 
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technical people on an IBM 370 system. Separately- 
compiled Pascal modules communicate through a data- 
base, called a compool, of common symbols and their 
absolute addresses. Because of its large size (90 mega- 
bytes, 42,000 names), a compool is stored as a base tree 5 
of objects plus some incremental revisions. A simple 
consistency check can be applied by a link editor to 
determine that two modules were compiled with mutu- 
ally-inconsistent compools, since references to code are 
stamped with the time after which the object file had to 10 
be recompiled. 

Management of a project this size poses huge prob- 
lems. Many of their problems were caused by the lack 
of facilities for separate compilation in standard Pascal, 
such as interface-implementation distinctions. The com- 15 
pool includes all symbols or procedures and variables 
that are referenced by modules other than the module in 
which they are declared. This giant interface between 
modules severely restricts changes that affect more than 
one separately-compiled module. Such a solution is only 20 
suitable in projects that are tightly managed. Their use 
of differential-updates to the compool and creation 
times to check consistency makes independent changes 
by programmers on different machines possible, since 
conflicts will ultimately be discovered by the link edi- 25 
tor. 

(7) Mesa, C/Mesa and Cedar 

Reference is now made to the Cedar/Mesa Environ- 
ment developed at Palo Alto Research Center of Xerox 
Corporation. The software version management system 30 
or system modeller of the instant invention is imple- 
mented on this enviroment. However, it should be clear 
to those skilled in the art of organizing software in a 
distributed environment that the system modeller may 
be implemented in other programming systems involv- 35 
ing a distributed environment and is not dependent in 
principle on the Cedar/Mesa environment. In other 
^ words, the system modeller may handle descriptions of 
software systems written in other programming lan- 
guages. However, since the system modeller has been 40 
implemented in the Cedar/Mesa environment, sufficient 
description of this environment is necessary to be famil- 
iar with its characteristics and thus better understand 
the implementation of the instant invention. This de- 
scription appears briefly here and more specifcally later 45 
on. 

The Mesa Language is a derivative of Pascal and the 
Mesa language and programming is generally disclosed 
and discussed in the published report of James G. 
Mitchell et al, "Mesa Language Manual, Version 5.0", 50 
Xerox PARC Technical Report CSL-79-3, April 1979. 
Mesa programs can be one of two kinds: interfaces or 
definitions and implementations. The code of a program 
is in the implementation, and the interface describes the 
procedures and types, as in Pascal, that are available to 55 
client programs. These clients reference the procedures 
in the implementation file by naming the interface and 
the procedure name, exactly like record or structure 
qualification, e.g., RunTime.GetMemoryQ refers to the 
procedure GetMemory in the interface RunTime. The 60 
Mesa compiler checks the types of both the parameters 
and results of procedure calls so that the procedures in 
the interfaces are as strongly type-checked as local, 
private procedures appearing in a single module. 

The interconnections are implemented using records 65 
of pointers to procedure bodies, called interface re- 
cords. Each client is passed a pointer to an interface 
record and accesses the procedures in it by dereferenc- 



ing once to get the procedure descriptors, which are an 
encoded representation sufficient to call the procedure 
bodies. 

A connection must be made between implementa- 
tions (or exporters) and clients (or importers) of inter- 
faces. In Mesa this is done by writing programs in 
C/Mesa, a configuration language that was designed to 
allow users to express the interconnection between 
modules, specifying which interfaces are exported to 
which importers. With sufficient analysis, C/Mesa can 
provide much of the information needed to recompile 
the system. However, C/Mesa gives no help with ver- 
sion control since no version information can appear in 
C/Mesa configurations. 

Using this configuration language, users may express 
complex interconnections, which may possibly involve 
interfaces that have been renamed to achieve informa- 
tion hiding and flexibility of implementation. In prac- 
tice, very few configuration descriptions are anything 
more than a list of implementation and client modules, 
whose interconnections are resolved using defaulting 
rules. 

A program called the Mesa Binder takes object files 
and configuration descriptions and produces a single 
object file suitable for execution. See the Article of 
Hugh C. Lauer and Edwin H. Satterthwaite, "The Im- 
pact of Mesa on System Design", Proceedings of the 4th 
International Conference on Software Engineering, pp. 
174-182, 1979. Since specific versions of files cannot be 
listed in C/Mesa descriptions, the Binder tries to match 
the implementations listed in the description with flies 
of similar names on the invoker's disk. Each object file 
is given a 48-bit unique version stamp, and the imported 
interfaces of each module must agree in version stamp. 
If there is a version conflict, e.g., different versions of an 
interface, the Binder gives an error message and stops 
binding. Most users have elaborate command files to 
retrieve what they believe are suitable versions of files 
to their local disk. 

A Librarian, discussed in the Article of Thomas R. 
Horsley and William C. Lynch, "Pilot: A Software 
Engineering Case Study", Proceedings of the 4th Interna- 
tional Conference on Software Engineering, pp. 94-99, 
1979, is available to help control changes to software in 
multi-person projects. Files in a system under its control 
can be checked out by a programmer. While a file is 
checked out by one programmer, no one else is allowed 
to check it out until it has been checked in. While it is 
checked out, others may read it, but no one else may 
change it. 

In one very large Mesa-language project, which is 
exemplified in the Article of Eric Harslem and Leroy E. 
Nelson, "A Retrospective on the Development of Star" 
Proceedings of the 6th International Conference on Soft- 
ware Engineering, September 1982, programmers submit 
modules to an integration service that recompiles all 
modules in a system quite frequently. A newly-com- 
piled system is stored on a file system and testing begins. 
A team of programmers, whose only duty is to perform 
integrations of other programmer's software, fix incom- 
patibilities between modules when possible. The major 
disadvantage of this approach is the amount of time 
between a change made by the programmer and when 
the change is tested. 

The central concern with this environment is that 
even experienced progranraDers have a problem manag- 
ing versions of Mesa or Cedar modules. The lack of a 
uniform file system, lack of tools to move version-con- 
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sistent sets of modules between machines, and lack of 
complete descriptions of their systems contribute to the 
problem. 

The first solution developed for version mangement 
of files is based on description files, also designated as 5 
DF files. The DF system automates version control for 
the user or programmer. This version management is 
described in more detail later on because experience 
with it is what led to the creation of the version manage- 
ment system of the instant invention. Also, the version 10 
management of the instant invention includes some 
functionality of the DF system integrated into an auto- 
matic program development system. DF files have in- 
formation about software versions of files and their 
locations. DF files that describe packages of software 15 
are input to a release process. The release process 
checks the submitted DF files to see if the programs 
they describe are made from compatible versions of 
software, and, if so, copies the files to a safe location. A 
Release Tool performs these checks and copies the files. 20 
If errors in DF files are found and fixed employing an 
interactive algorithm. Use of the Release Tool allows 
one making a release, called a Release Master, to release 
software with which he may in part or even to a large 
extent, not be familiar with. 25 

SUMMARY OF THE INVENTION 

According to this invention, the system modeller 
provides for automatically collecting and recompiling 
updated versions of component software objects com- 30 
prising a software program for operation on a plurality 
of personal computers coupled together in a distributed 
software environment via a local area network. As used 
herein, the term "objects" generally has reference to 
source modules or files, object modules or files and 35 
system models. The component software objects are 
stored in various different local and remote storage 
means throught the environment. The component soft- 
ware objects are periodically updated, via a system 
editor, by various users at their personal computers and 40 
then stored in designated storage means. 

The system modeller employes models which are also 
objects. Each of the models is representative of the 
source versions of a particular component software 
object and contain object pointers including a unique 45 
name of the object, a unique identifier descriptive of the 
cronoiogical updating of its current version, informa- 
tion as to an object's dependencies on other objects and 
a pathname representative of the residence storage 
means of the object. Means are provided in the system 50 
editor to notify the system modeller when any one of 
the objects is being edited by a user and the system 
modeller is responsive to such notification to track the 
edited objects and alter their respective models to the 
current version thereof. The system modeller upon 55 
command is adapted to relieve and recompile source 
files corresponding to altered models and load the bi- 
nary files of the altered component software objects and 
their dependent objects into the user's computer. 

The system modeller also includes accelerator means 60 
to cache the object pointers in the object models that 
never change to thereby avoid further retrieving of the 
objects to parse and to discern the object pointers. The 
accelerator means for the models includes (1) an object 
type table for caching the unique name of the object and 65 
its object type to enhance the analysis of a model by the 
modeller, (2) a projection table for caching the unique 
pame of the source object, names of object parameters. 



compiler switches and compiler version to enhance the 
translation of objects into derived objects, and (3) a 
version map for caching the object pathname. 

The system modeller is an ideal support system in a 
distributed software environment for noting and moni- 
toring new and edited versions of objects or modules, 
i.e., source or binary or model files, and automatically 
managing the compilation, loading saving of such mod- 
ules as they are produced. Further, the system modeller 
provides a means for organizing and controlling soft- 
ware and its revision to provide automatic support for 
several different kinds of program development cycles 
in a programming system. The modeller handles the 
daily evolution of a single module or a small group of 
modules modified by a single person, the assembly of 
numerous modules into a large system with complex 
interconnections, and the formal release of a program- 
ming system. The modeller can also efficiently locate a 
large number of modules in a big distributed file system, 
and move them from one machine to another to meet 
operational requirements or improve performance. 

More particularly, the system modeller automatically 
manages the compilation, loading and saving of new 
modules as they are produced. The system modeller is 
connected to the system editor and is notified of new 
and edited versions of files as they are created by the 
system editor, and automatically recompiles and loads 
new versions of software. The system user decribes his 
software in a system model that list the versions of files 
used, the information needed to compile the system, and 
the interconnections between the various modules. The 
modeller allows the user or programmer to maintain 
three kinds of information stored in system models. The 
models, which are similar to a blueprint or schematic, 
describe particular versions of a system. A model com- 
bines in one place (1) information about the versions of 
files needed and hints about their locations, (2) addi- 
tional information needed to compile the system, and (3) 
information about interconnections between modules, 
such as which procedures are used and where they are 
defined. To provide fast response, the modeller behaves 
like an incremental compiler so that only those software 
modules that have experienced a change are analyzed 
and recompiled. 

System models are written in a SML language, which 
allows complete descriptions of all interconnections 
between software modules in the environment. Since 
these interconnections can be very complicated, the 
language includes defaulting rules that simplify system 
models in common situations. 

The programmer uses the system modeller to manip- 
ulate systems described by the system models. The sys- 
tem modeller (1) manipulates the versions of files listed 
in models (2) tracks changes made by the programmer 
to files listed in the models, (3) automatically recompiles 
and loads the system, and (4) provides complete support 
for the release process. The modeller recompiles new 
versions of modules and any modules that depend on 
them. 

The advantages of the system modeller is (1) the use 
of a powerful module interconnection language that 
expresses interconnections, (2) the provision of a user 
interface that allows interactive use of the modeller 
while maintaining an accurate description of the system, 
and (3) the data structures and algorithms developed to 
maintain caches that enable fast analysis of modules by 
the modeller. These advantages are further expandable 
as follows. 



11 



4,558,413 



12 



First, the system modeller is easy to use, perfonn 
functions quickly and is to run while the programmer is 
developing his software and automatically update sys- 
tem descriptions whenever possible. It is important that 
a software version management system be used while 5 
the programmer is developing software so he can get 
the most benefit from them. When components are 
changed, the descriptions are adjusted to refer to the 
changed components. Manual updates of descriptions 
by the programmer would slow his software develop- 10 
ment and proper voluntary use of the system seems 
unlikely. The system modeller functioning as an incre- 
mental compiler, i.e. only those pieces of the system that 
are actually change are recompiled, loaded and saved. 

Second, the exemplified computing environment 15 
upon which the described system modeller is utilized is 
a distributed personal computer environment with the 
computers connected over an Ethernet local area net- 
work (LAN). This environment introduces two types of 
delays in access to versions of software stored in files: 20 
(1) if the file is on a remote machine, it has to be found, 
and (2) once found, it has to be retrieved. Since retrieval 
time is determined by the speed of file transfer across 
the network, the task of retrieving files is circumvented 
when the information desired about a file can be com- 25 
puted once and stored in a database. For example, the 
size of data needed to compute recompilation informa- 
tion about a module is small compared to the size of the 
module's object file. Recompilation information can be 
saved in a database stored in a file on the local disk for 30 
fast access. In cases where the file must be retrieved 
determining which machine and directory has a copy of 
the version desired can be very time consuming. The 
file servers can deliver information about versions of 
files in a remote file server directory at a rate of up to six 35 
versions per second. Since directories can have many 
hundreds of versions of files, it is not practical to enu- 
merate the contents of a file server while looking for a 
particular version of a file. The solution presented here 
depends on the construction of databases for each soft- 40 
ware package or system that contains information about 
file locations. 

Third, since many software modules, e.g., Cedar 
software modules, have a complicated interconnection 
structure, the system modeller includes a description 45 
language that can express the interconnection structure 
between the modules. These interconnection structures 
are maintained automatically for the programmer. 
When new interconnections between modules are 
added by the programmer, the modeller updates the 50 
model to add the interconnection when possible. This 
means the user has to maintain these interconnections 
very seldom. The modeller checks interconnections 
listed in models for accuracy by checking the parame- 
terization of modules. 55 

Further advantages, objects and attainments together 
with a fuller understanding of the invention will be- 
come apparent and appreciated by referring to the fol- 
lowing description and claims taken in conjunction with 
the accompanying drawings. 60 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an illustration of a dependency graph for a 
prior art software management system. 

FIG. 2 is an illustration for a hierarchy of another 65 
prior art software management system. 

FIG. 3 is an illustration of the description specifiers of 
a still another prior art software management system. 



FIG. 4 is an illustration of a Cedar system client and 
implementor module dependency. 

FIG. 5 is an illustration of a Cedar system source and 
object file dependency. 

FIG. 6 is an illustration of a dependency graph for a 
Cedar System. 

FIG. 7 is an example of a typical distributed com- 
puter evironment. 

FIG. 8 is a flow diagram of the steps for making a 
release in a distributed computer environment. 

FIG. 9 is a dependency graph for DF files in the boot 
file. 

FIG. 10 is a dependency graph illustrative of a detail 
in the boot file. 

FIG. 11 is a dependency graph for interfaces. 

FIG. 12 is a dependency graph for files outside the 
boot file. 

FIGS. 13a and 13b illustrate interconnections be- 
tween implementation and interface modules. 

FIG. 14 illustrates two different versions of a client 
module. 

FIGS. 15a and 15* illustrate a client module to IM- 
PORT different versions of the module that EXPORTS. 

FIG. 16 illustrates a client module with different 
types of objects. 

FIG. 17 is an example of a model. 

FIG. 18 are examples of object type and projection 
tables. 

FIG. 19 is an example of a version map. 

FIG. 20 is an illustration the user's screen for system 
modeller in the Cedar system. 

FIG. 21 is a flow diagram illustrating the steps the 
user takes in employing the system modeller. 

FIG. 22 is a modeller implementation flow diagram 
illustrating "StartModel" analysis. 

FIG. 23 is a modeller implementation flow diagram 
illustrating computation analysis. 

FIG. 24 is a modeller implementation flow diagram 
illustrating loader analysis. 

FIG. 25 illustrates the Move Phase two of the release 
utilitity. 

FIG. 26 illustrates the Build Phase three of the release 
utility. 

FIG. 27 is an example of a version map after release. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

1. The Cedar Environment, DF Software and the 
Release Process For The Cedar Environment 

One kind of management system of versions of soft- 
ware for a programmer in a distribution environment is 
a version control system of modest goals utilizing DF 
files. Each programmer lists files that are part of his 
system in a description file which is called a DF file. 

Each entry in a DF file consists of a file name, its 
location, and the version desired. The programmer can 
use tools to retrieve files listed in a DF file and to save 
new versions of files in the location specified in the DF 
file. Because recompiling the files in his system can 
involve use of other systems, DF files can refer also to 
other DF files. The programmer can verify that, for 
each file in the DF file, the files it depends on are also 
listed in the DF file. 

DF files are input to a release process that verifies 
that the cross-package references in DF files are valid. 
The dependencies of each file on other files are checked 
to make sure all files needed are also part of the release. 



13 



4,558,413 



14 



The release process copies all files to a place where they 
cannot be erroneously destroyed or modified. 

The information about file location and file versions 
in DF files is used by programs running in the distrib- 
uted programming environment. Each programmer has 5 
a personal computer on which he develops software. 
Each personal computer has its own disk and file sys- 
tem. Machines are connected to other machines using 
an Ethernet local area network. Files can be transferred 
by explicit request from the file system on one machine '0 
or computer to another machine or computer. Often 
transfers occur between a personal machine and a file 
storage means, e.g., a file server, which is a machine 
dedicated to servicing file requests, i.e., storing and 
permitting the retrieval of stored files. " 

The major research contributions of the DF system 
are (1) a language that, for each package or system 
described, differentiates between (a) files that are part of 
the package or system and (b) files needed from other 
packages or systems, and (2) a release process that does 
not place too high a burden on programmers and can 
bring together packages being released. A release is 
complete if and only if every object file needed to com- 
pile every source file is among the files being released. ., 
A release is consistent if, and only if, only one version of 
each package is being released and every other package 
depends on the version being released. The release pro- 
cess is controlled by a person acting as a Release Mas- 
ter, who spends a few days per monthly release running jq 
programs that verify that the release is consistent and 
complete. Errors in DF files, such as references to non- 
existent files or references to the wrong versions of files, 
are detected by a program called the Release Tool. 
After errors are detected, the Release Master contacts jj 
the implementor and has him fix the appropriate DF 
file. 

Releases can be frequent since performing each re- 
lease imposes a low cost on the Release Master and on 
the programmers. The Release Master does not need to 40 
know details about the packages being released, which 
is important when the software of the system becomes 
too large to be understood by any one programmer. The 
implementor of each package can continue to make 
changes to his package until the release occurs, secure 45 
in the knowledge that his package will be verified be- 
fore the release completes. Many programmers make 
such changes at the last minute before the release. The 
release process supports a high degree of parallel activ- 
ity by programmers engaged in software development 50 
of a large dsitributed programing environment. 

The DF system does not offer all that is needed to 
automate software development. DF files have only 
that information needed to control versions of files. No 
support for automatic recompilation of changed soft- 55 
ware modules is provided in the DF system. The only 
tool provided is a consistency checker that verifies that 
an existing system does not need to be recompiled. 

In order to better understand the software version 
control system of the instant invention, a general under- 60 
standing of the programming environment in which it is 
implemented is desirable. The programming environ- 
ment is called Cedar. First, some general characteristics 
of Cedar. 

The Cedar system changes frequently, both to intro- 65 
duce new function and also to fix bugs. Radical changes 
are possible and may involve recompilation of the entire 
system. System requirements are: 



1. The system must manage these frequent changes 
and must give guarantees about the location and consis- 
tency of each set of files. 

2. Each consistent set of Cedar software is called a 
"Cedar Release", which is a set of software modules 
carefully packaged into a system that can be loaded and 
run on the programmer's personal machine. These re- 
leases must be carefully stored in one place, docu- 
mented and easily accessible. 

3. Cedar releases should be accomplished, e.g., as 
often as once a week, since frequent releases make avail- 
able in a systematic way new features and bug fixes. The 
number of users or programmers is small enough that 
releases do not need to be bug-free since users are gen- 
erally tolerant of bugs in new components or packages 
in the system. When bugs do occur, it must be clear who 
is responsible for the software in which the bug occurs. 

4. The system must minimize inconvenience to imple- 
mentors and cannot require much effort from the per- 
son in charge of constructing the release. The scheme 
must not require a separate person whose sole job is 
control and maintenance of the system. 

5. The system must be added on top of existing pro- 
gram development facilities, since it is not possible to 
change key properties of such a large distributed pro- 
graming environment. 

A limited understanding of the dependency relation- 
ships in the Cedar software systems is necessary, i.e., an 
overview of Cedar modules and dependencies. 

The view taken in the Cedar system is that the soft- 
ware of a system is completely described by a single unit 
of text. An appropriate analogy is the sort of card deck 
that was used in the 1950s to boot, load and run a bare 
computer. Note that everything is said explicitly in such 
a system description. There is no operator intervention, 
such as to supply compiler switches or loader options, 
after the "go" button is initiated. In such a description 
there is no issue of "compilation order", and "version 
control" is handled by distributing copies of the deck 
with a version number written on the top of each copy. 

The text of such a system naturally will have integral 
structure appropriate to the machine on which it runs as 
well as to the software system itelf The present system 
is composed of modules that are stored as text in files 
termed modules or objects. This representation pro- 
vides modularity in a physical representation, i.e., a file 
can name other files instead of literally including their 
text. In Cedar, these objects are Cedar modules or sys- 
tem models. This representation is convenient for users 
to manipulate, it allows sharing of identical objects or 
modules, and facilitates the separate compilation of 
objects or modules. But it is important to appreciate that 
there is nothing essential in such a representation. In 
principle, a system can always be expressed as a single 
text unit. 

Unless care is taken, however, the integrity of the 
system will be lost, since the contents of the named files 
may change. To prevent this, files are abstracted into 
named objects, which are simply pieces of text. The file 
names must be unique and objects must be immutable. 
By this it is meant that each object has a unique name, 
never used for any other object. The name is stored as 
part of the object, so there is no doubt about whether a 
particular collection of bits is the object with a given 
name. A name is made unique by appending a unique 
identifier to a human-sensible string. 

The contents of an object or module never change 
once the object is created. The object may be erased, in 
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which case the contents are no longer accessible. If the 
file system does not guarantee immutability, it can be 
ensured by using a suitable checksum as the unique 
identifier of the object. 

These rules ensure that a name can be used instead of 
the text of a module without any loss of integrity, in the 
sense that either the entire text of a system will be cor- 
rectly assembled, or the lack of some module will be 
detected. 

In Cedar, a Cedar module A depends on another 
Cedar module B when a change to B may require a 
change to A. If module A depends on module B, and B 
changes, then a system that contains the changed ver- 
sion of B and an unchanged version of A could be in- 
consistent. Depending on the severity of the change to 
B, the resulting system may not work at all, or may 
work while being tested but fail after being distributed 
to users. Cedar requires inter-module version checking 
between A and B that is very similar to Pascal type- 
checking for variables and procedures. As in Pascal, 
Cedar's module version checking is designed to detect 
inconsistency as soon as possible at compile time so that 
the resulting system is more likely to run successfully 
after development is completed. 

Each Cedar module is represented as a source file 
whose names, for example, ends in "Mesa". The Cedar 
compiler produces an object file whose name, for exam- 
ple, ends in "Bed". Each object file can be uniquely- 
identified by a 48-bit version stamp so no two object 
files have the same version stamp. Cedar modules de- 
pend on other modules by listing in each object file the 
names and 48-bit version stamps of object files they 
depend on. A collection of modules that depend on 
each other are required to agree exactly in 48-bit ver- 
sion stamps. For example, module A depends on version 
35268AADB3E4 (hexadecimal) of module B, but B has 
been changed and is now version 31258FAFBFE4, then 
the system is inconsistent. 

The version stamp of a compiled module is a function 
of the source file and the version stamps of the object 40 
files on which it depends on. If module A depends on 
module B which in turn depends on module C, and C is 
changed and compiled, then when B and A are com- 
piled their version stamps will change because of the 
change to C. 

There are three kinds of software modules in Cedar. 
They are called interface, implementation, and configu- 
ration. There are two programs that produce object 
files. They are the Cedar Compiler and the Cedar 
Binder. 

Executing code for a Cedar system is contained in an 
implementation module. Each implementation module 
can contain procedures, global variables, and local vari- 
ables that are scoped using Pascal scoping rules. To call 
a procedure defined in another implementation module, 
the caller or client module must IMPORT a interface 
module that defines the procedure's type i.e. the type of 
the procedure's argument and result values. This inter- 
face module must be EXPORTED by the implementa- 
tion module that defines it. This module is called the 
implementor. 

Both the client and implementor modules depend on 
the interface module. This dependency is illustrated in 
FIG. 3. If the interface is recompiled, both client and 
implementor must be recompiled. The client and imple- 
mentor modules do not depend on each other, so if 
either is compiled the other does not need to be. Thus, 
Cedar uses the interface-implementor module distinc- 
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tion to provide type safety with minimal recompilation 
cost. 

A compiler-produced object file depends on (1) the 
source module that was compiled and (2) the object files 
of any interfaces that this module IMPORTS or EX- 
PORTS. This dependency is illustrated in FIG. 5. These 
interface modules are compiled separately from the 
implementations they described, and interface object 
files contain explicit dependency information. In this 
respect. Cedar differs from most other languages with 
interface or header files. 

Another level of dependency is introduced by config- 
uration modules, which contain implementation mod- 
ules or other configuration modules. The programmer 
describes a set of modules to be packaged together as a 
system by writing a description of those modules and 
the interconnections among them in a language called 
C/Mesa. A C/Mesa description is called a configura- 
tion module. The source file for a configuration is input 
to the Cedar Binder which then produces an object file 
that contains all the implementation module object files. 
The Binder ensures the object file is composed of a 
logically-related set of modules whose IMPORTs and 
EXPORTS all agree in version. Large system of mod- 
ules are often made from a set of configurations called 
sub-configurations. A configuration object file depends 
on (1) its source file and (2) the sub-configurations and 
implementation object files that are used to bind the 
configuration. These object files can be run by loading 
them with the Cedar Loader which will resolve any 
IMPORTS not bound by the Binder. 

In general, a Cedar system has a dependency graph 
like that illustrated in FIG. 6. 

Each Cedar programmer has its own personal com- 
puter, which is connected to other computers by an 
Ethernet local area network (LAN). Most files compris- 
ing a system are stored on central file servers dedicated 
to serving file requests and are copied from the central 
file server(s) to the personal machine by an explicit 
command, which is similar to the Arpanet "ftp" com- 
mand. FIG. 7 illustrates a typical environment. In such 
an environment, a plurality of workstations comprising 
a personal computer or machine 10 with keyboard, 
display and local memory are connected to an Ethernet 
LAN via cable 12. Also connected to cable 12 is file 
server 14 comprising a server computer 16 and storage 
disk units 18 capable of storing large amounts of files 
under designated path or directory names. Cable 12 is 
also connected to a gateway computer 20 which pro- 
vides access and communication to other LANs. 

The user of a machine 10 must first install a boot file 
that is given control after the machine is powered on. 
Cedar users install the Cedar boot file that contains the 
operating system and possibly pre-loaded programs. 

Since the Binder and Loader ensure that the version 
stamps of Cedar modules all agree, all Cedar modules 
could be bound together and distributed to all users for 
use as the Cedar boot file. However, users who wanted 
to make changes would have to re-bind and load the 
system every time they changed a module to test their 
changes. The resulting boot file would be very large 
and difficult to transfer and store on the disks of the 
personal machines. To avoid these problems, Cedar 
users install this boot file on their machine, which con- 
tains a basic system to load and execute Cedar pro- 
grams, a file system, and a pre-loaded editor and then 
retrieve copies of programs they want to run that are 
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not already in the boot file. These programs are thus 
loaded as they are needed. 

Changes to these programs are possible as long as the 
versions of interfaces pre-loaded in the Cedar boot file 
agree with the versions IMPORTed by the program 5 
being loaded. Since the boot file EXPORTS are more 
than 100 interfaces, the programmer can quickly be- 
come confused by version error messages for each of 
the interfaces he uses. This problem could be solved 
simply by disallowing changes to the Cedar interfaces ^^ 
except, say, once annually. However, it is desirable to 
be able to adjust interfaces frequently to reflect new 
features and refinements as they are understood. 

Control of software in module interconnection lan- 
guages is analogous to control over types in conven- 
tional programming languages, such as Pascal. Still 
opposed by some, strong type-checking in a language 
can be viewed as a conservative approach to program- 
ming, where extra rules, in the form of type equiva- 
lence, are imposed on the program. Proponents claim 
these rules lead to the discovery of many programming 
errors while the program is being compiled, rather than 
after it has started execution. 

Like strong type-checking of variables, type-check- 
ing in a language like Cedar with the explicit notion of 
an interface module can be performed at the module 
level so that incompatibilities between modules can be 
resolved when they are being collected together rather 
than when they are executing. As in the strong type- jq 
checking case, proponents claim this promotes the dis- 
covery of errors sooner in the development of pro- 
grams. 

Incompatible versions of modules, like incompatible 
types in a programming languages, may be corrected by 35 
the programmers involved. Many times, complex and 
subtle interdependencies exist between modules, espe- 
cially when more than a few programmers are involved 
and the lines of communication between them are 
frayed or partially broken. In the Cedar Xerox environ- ^ 
ment, where each module is a separate file and develop- 
ment occurs on different personal computers or ma- 
chines, module-level type-checking is more important 
than type-checking of variables in conventional pro- 
gramming languages. This is because maintaining inter- 45 
module type consistency is by definition spread over 
different files, possibly on different computers by more 
than one programmer/user, while maintaining type- 
consistency of variables is usually localized in one file 
by one programmer/user on one computer. 50 

Users in Cedar are required to group logically-related 
files, such as the source and object files for a program 
they are developing, into a package. Each software 
package is described by a DF file that is a simple text 
file with little inherent structure that is editable by the 55 
programmer/user. The DF file lists all the files grouped 
together by the implementor as a package. For each file, 
the DF file gives a pathname or location where the file 
can be found and information about which version is 
needed. 60 

In Cedar, files are stored on remote file servers with 
names like "Ivy" or "Indigo" and have path or direc- 
tory names, e.g., "Levin >BTrees>". A file like 
"BTreeDefs.Mesa" would be referenced as "[Ivy] < Le- 
vin >BTrees>BTreeDefs.Mesa". In addition, when 65 
created, each file is assigned a creation time. Therefore 
"BTreeDefs.Mesa Of May 13, 1982 2:30 PM" on 
"[Ivy] < Levin > BTrees>" defines a particular version. 



A DF file is a list of such files. For syntactic group- 
ing, we allow the user to list files grouped under com- 
mon directories. The implementor of a B-tree package, 
for example, might write in his DF file, called 
BTrees.DF: 



Directory [Ivyl < Levin > BTrees > 



BTreeDefs.Mesa 



2-Oct-81 



15:43:09 



to refer to the file [Ivy] < Levin > BTrees > BTreeDefs. - 
Mesa created at 2-Oct-81 15:43:09. 

If, for example, the BTree package included an object 
file for BTreeDefs.Mesa, and an implemMtation of a 
B-tree package, it could be described in BTrees.DF as: 



Directory [Ivy] < Levin > BTrees> 



BTreeDefs. Mesa 
BTreeDefs. Bed 
BTreelmpl.Mesa 
BTreelmpl.Bed 



2-OCI-81 
2-Oct-8I 
2-Oct-81 
2-Oct-8I 



13:43:09 
16:00:28 
15:28:54 
16:44:31 



Two different DF files could refer to different ver- 
sions of the same file by using references to files with 
different create dates. 

There are cases where the programmer wants the 
newest version of a file. If the notation, ">", appears in 
place of a create time notation, the DF file refers to the 
newest version of a file on the directory listed in the DF 
file. For example, 



Directory [Ivy] < Pilot >Defs> 



Space.Bed 



refers to the newest version of Space.Bed on the direc- 
tory [Ivy] < Pilot >Defs>. This is used mostly when 
the file is maintained by someone other than the pro- 
grammer and is content to accept the latest version of 
the file. 

Users are encouraged to think of the local disk on 
their personal computer as a cache of files whose "true" 
locations are the remote servers. A program called 
BringOver assures the versions listed in a DF file are on 
the local computer disk. 

Since DF files are editable, the programmer who 
edits, for example, BTreeDefs.Mesa could, when ready 
to place a new copy on the server.Ivy, store it manually 
and edite the DF file to insert the new create time for 
the new version. 

For large numbers of files, this would always be error 
prone, so a StoreBack program provides automatic 
backup of changed versions (1) by storing files that are 
listed in the DF file but whose create date differs from 
the one listed in the DF on the assumption that the file 
has been edited, and (2) by updating the DF file to list 
the new create dates. The DF file is to be saved on the 
file server, so we allow for a DF self-reference that 
indicates where the DF file is stored. For example, in 
BTrees.DF: 



Directory [Ivy] < Levin > BTrees > 



BTrees.DF 
BTreeDefs.Mesa 
BTreeDefs. Bed 



20-Oct-81 
2-Oct-81 
2-C)ct-81 



9:35:09 
15:43:09 
I6«):28 
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Directory [Ivy] < Levin >BTrees> 



BTreelmpl.Mesa 
BTreelmpl.Bed 



2-Oct-81 
2-Oct-81 



13:28:54 
16:44:31 



the first file listed is a self-reference. The StoreBack 
program arranges that the new version of BTrees.DF 
will have the current time as its create date. 

The Cedar system itself is a set of implementaton lo 
modules that export common system interfaces to the 
file system, memory allocator, and graphics packages. 
Assume the B-tree package uses an interface from the 
allocator. The user makes this dependency explicit in 
their DF file. The BTree package will then IMPORT 15 
the interface "Space", which is stored in object form in 
the file "Space.Bcd". 

The BTree DF package will reflect this dependency 
by "importing" Space.Bcd from a DF file "Pilotlnter- 
faces.DF" that lists all such interfaces. BTrees.DF will 20 
have an entry: 



Imports [lndigo]<Cedar>Top> 
PiIotIiUerfaces.DF Of 
Using[Space.Bed] 



2-Oct-81 



15:43:09 
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TTie "Imports" in a DF file is analogous to the IM- 
PORTS in a Cedar program. As in Cedar modules, 
BTrees.DF depends on Pilot.DF. Should "Space.Bcd" 
and its containing DF file "Pilot.DF" change, then 
BTrees.DF may have to also change. 

The programmer/user may want to list special pro- 
grams, such as a compiler-compiler or other preproces- 
sors, that are needed to make changes to his system. 
This is accomplished using the same technique of IM- " 
PORTing the program's DF file. 

For the individual programmer, there are two direct 
benefits from making dependency information explicit 
in his DF file. First, the BringOver program will ensure 
that the correct version of any imported DF files are on * 
the local disk, so programmers can move from one 
personal computer to another and guarantee they will 
have the correct version of any interfaces they refer- 
ence. Second, listing dependency information in the DF 
file puts in one place information that is otherwise scat- ^5 
tered across modules in the system. 

How does the programmer/user know which files to 
list in his DF file? For large systems, under constant 
development, the list of files is long and changes fre- 
quently. The programmer can run a program VerifyDF 50 
that analyzes the files listed in the DF file and warns 
about files that are omitted. VerifyDF analyzes the 
dependency graph, an example of which is illustrated in 
FIG. 6, and analyzes the versions of (1) the source file 
that was compiled to produce the object file and (2) all 55 
object files that this object file depends on. VerifyDF 
analyzes the modules listed in the DF file and constructs 
a dependency graph. VerifyDF stops its analysis when 
it reaches a module defined in another package that is 
referenced by IMPORTs in the DF. Any modules de- 60 
fined in other packages are checked for versionstamp 
equality, but no modules that they depend upon are 
analyzed, and their sources do not need to be listed in 
the package's DF file. 

VerifyDF understands the file format of object files 65 
and uses the format to discover the dependency graph, 
but otherwise it is quite general. For example, it does 
not differentiate between interface and implementation 



files. VerifyDF could be modified to understand object 
files produced by other language compilers as long as 
they record all dependencies in the object file with a 
unique version stamp. For each new such language, 
VerifyDF needs (1) a procedure that returns the object 
version stamp, source file name and source create time, 
and (2) a procedure that returns a list of object file 
names and object version stamps that a particular object 
file depends on. 

If the programmer lists all such package and files he 
depends on, then some other programmer on another 
machine will be able to retrieve, using BringOver com- 
mand, all the files he needs to make a change to the 
program and then run StoreBack to store new versions 
and produce a new DF file. 

Using these tools, that is BringOver, StoreBack, Veri- 
fyDF, the programmer/user can be sure he has a DF 
file that lists all the files that are needed to compile the 
package (completeness) and that the object files were 
produced from the source files listed in the DF file, and 
there are no version stamp discrepancies (consistency). 
The programmer can be sure the files are stored on 
central file servers and can turn responsibility for a 
package over to another programmer by simply giving 
the name of the DF file. 

DF files can be used to describe releases of software. 
Releases are made by following a set of Release Proce- 
dures, which are essentially managerial functions by a 
Release Master and requirements placed on implemen- 
tors/users. A crucial element of these Release Proce- 
dures is a program called the Release Tool, which is 
used to verify that the release is consistent and com- 
plete, and is used to move the files being released to a 
common directory on a designated file server. 

If the packages a programmer depends on change 
very seldom, then use of the tools outlined above is 
sufficient to manage versions of software. However, 
packages that almost everyone depends on may be 
changed. A release must consist of packages that, for 
example, all use the same versions of interfaces supplied 
by others. If version mismatches are present, modules 
that IMPORT and EXPORT different versions of the 
same interface will not be connected properly by the 
loader. In addition to the need for consistency and com- 
pleteness across an entire release, the component files of 
a particular release must be carefully saved somewhere 
where they are readily available and will not be 
changed or deleted by mistake, until an entire release is 
no longer needed. 

The administration of Cedar releases are organized 
around an implementor/user who is appointed Release 
Master. In addition to running the programs that pro- 
duce a release, he is expected to have a general under- 
standing of the system, to make decisions about when to 
try to make a release, and to compose a message de- 
scribing the major changes to components of the re- 
lease. 

Once he decides to begin the release process after 
conferring with other implementors and users, the Re- 
lease Master sends a "call for submissions" message 
through an electronic mail system of the distributed 
system to a distribution list of programmers/users who 
have been or are planning to contribute packages to the 
release. Over a period of a few days, implementors/us- 
ers are expected to wait until new versions of any pack- 
ages they depend on are announced, produce a new 
version on some file server and directory of their choos- 
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ing, and then announce the availability of their own since more than one package has a queue implementa- 

packages. tion, but each version is carefully separated and the 

One message is sent per package, containing, for versions do not conflict, 

example, "New Version of Pkg can be found on [Ivy- Phase one also checks for common blunders, such as 

]< Schmidt >Pkg.DF, that fixes the bug . . . ". Pro- 5 a DF file that does not refer to newest versions of DF 

grammers who depend on Pkg.DF are expected to edit files it depends on, or a DF file that refers to system or 

their DF files by changing them to refer to the new program files that do not exist where the DF file indi- 

version. Since often it is the newest version, clients of gates they can be found. The Release Master makes a 

Pkg.DF usually replace an explicit date by the notation, ijgt^ package by package, of such blunders and calls 

">". They might refer to Pkg.DF by inserting: lo each user and notifies them they must fix their DF files. 

Phase one is usually repeated once or twice until all 

tapom[lvy]<Schmidt>Pkg.DFOf> s"ch problems are fixed and any other warnings are 

Using[Fiiei.Bed. Fiie2.Bedl judged benign. Phase two guarantees system wide com- 

^ pleteness of a release by running Verify DF will warn of 

. p „. '5 files that should have been listed in the DF file but were 

'" If tTe package is not changed, a message to that effect o™"«d^ Implementor/users are expected to run Veri- 

will be Lt. These submisJons do not appear in lock ^/^^ themselves, but during every release, ot is easy 

step since changes by one implementor may affect pack- ^^r at least one to forget. Any omissions must be fixed 

ages that are "above" them in the dependency graph. ,(, by the implementor/user. 

This pre-release integration period is a parallel explo- Once phases one and two are completed successfully, 

ration of the dependency graph of Cedar software by its the Release Master is fairly certam there are no out- 

implementor/users. If an implementor is unsure standing version of system composition problems, and 

whether he will have to make changes as a result of he can proceed to phase three. 

lower level bug fixes, for instance, he is expected to ,, To have control over the deletion of old releases, 

contact the implementor of the lower package and co- phase three moves all files that are part of a release to a 

ordinate with him. Circular DF-dependencies may oc- directory that is mutable only by the Release Master. 

cur, where two or more packages use interfaces ex- Moving files that are part of the release also helps users 

ported by each other. In circular cases, the DF files in by centralizing the files in one phase. The DF files 

the cycle have to be announced at the same time or one „ produced by users, however, refer to the files on their 

of the DF files has to be split into two parts: a bottom working directories. We therefore require that every 

halfthat the other DF file depends on and a top half that file mentioned in the DF files that are being released 

depends on the other DF file. have an additional phrase "ReleaseAsreleasePlace". 

The Release Master simply monitors this integration The BTrees.DF example would look like: 
process and when the final packages are ready, begins 
the release. FIG. 7 illustrates the steps being taken to 
accomplish a release. 

Once all packages that will be submitted to the re- 
lease are reaidy, the Release Master prepares a top-level 
DF file that lists all the DF files that are part of the 
release. Packages that are not changed relative to a 
previous release are also listed in this DF file. DF files 
are described using a construct similar to "Imports" 
discussed earlier. The contents of each DF file are refer- 
enced by an Include statement, e.g., 

*' which indicates a working directory as before and a 

Include [Ivy] < Levin >BTrees> BTrees.DF Of > place to put the Stable, released versions. By conven- 
tion, all such files must be released onto subdirectories 

refers to the newest version of the BTree package of [Indigo] < Cedar >. To make searching for released 

stored on Levin's working directory < Levin >BTr- DF files on the < Cedar > directory easier, each DF 

ees>. Include is treated as macro-substitution, where 50 {jj^.^ self-reference must release the DF file to the spe- 

the entire contents of BTrees.DF are analyzed by the cjai subdirectory < Cedar > Top >. When the third 

Release Tool as if they were listed directly in the top- p^ase is run, each file is copied to the release directory, 

level DF. e.g.^ B-tree files are copied to < Cedar >BTrees> and 

The Release Master uses the top-level DF as input to „g^ ^p fi^^ ^^^ written that describe these files in their 

phase one of the Release Tool. Phase one reads all the 55 jgig^sg positions, e.g., 
included DF files of the release and performs a system- 
wide consistency check. A warning message is given if 
there are files that are part of the release with the same 
name and different creation times (e.g., BTreeDefs.- 

Mesa of 20-May-82 15:58:23 and also another version of 60 
17-Apr-82 12:68:33). Such conflicts may indicate that 
two programmers are using different versions of the 
same interface in a way that would not otherwise be 
detected until both programs were loaded on the same 

computer. These warnings may be ignored in cases 65 
where the Release Master is convinced that no harm 

will come from the mismatch. For example, there may The additional phrase "CameFrom" is inserted as 

be more than one version of "Queue.Mesa" in a release comment saying where the file(s) were copied from. 



35 



40 



Directory [Ivy] < Levin >BTrees> 


Release As fIndigoK Cedar > Top > 


20-Oct-81 

2-Oct-81 
2-Oct-81 
2-Oct-81 
2-Oct-81 




BTrees.DF 

ReleaseAs [Indigol<Cedar>BTrees> 


9:35:09 


BTreeDefs.Mesa 
BTreeDefs.Bed 
BTreelmpl.Mesa 
BTreelmpl.Bed 


15:43:09 
16:00:28 
15:28:54 
16:44:31 



Directory [Indigo] < Cedar > Top > 






Came From [Ivy] < Levin >BTrees> 






BTrees.DF 


9-NOV-81 


10:32:45 


Directory [Indigo] < Cedar > BTrees > 






Came From [Ivy] < Levin > BTrees > 






BTreeDefs.Mesa 


2-OCI-81 


15:43:09 


BTreeDefs.Bed 


2-Oct-81 


16:00:28 


BTreelmpl.Mesa 


2-Oct-81 


15:28:54 


BTreelmpl.Bed 


2-Oct-81 


16:44:31 
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The other major function of phase three is to convert 
references using the "newest version" notation, ">", to 
be explicit dates, since "newest version" will change for 
every release. Phase three arranges that a reference like: 



Impom[Ivy]<Leviii>BTree»>BTrees.DF Of> 
UsingIBtreeDefs.Bed] 



becomes 



Impons [Indigo] <Cedar>BTrees>Btrees.DF Of date 
Came from [Ivy] < Levin >BTrees> 

Using [BTreePefs.Bed] 



10 



15 



where date is approximately the time that phase three is 
run. 

The notion of a "Cedar Release" has many advan- 
tages. In addition to a strong guarantee that the soft- 20 
ware will work as documented, it has an important 
psychological benefit to users as a firewall against disas- 
ters, since programmers are free to make major changes 
that may not work at all, and are secure in the knowl- 
edge that last release is still available to fall back upon. ^^ 
Since users can convert back and forth between re- 
leases, users have more control over which versions 
they use. There is nothing wrong with more than one 
such release being in use at one time by different pro- 
grammer/users, since each programmer has his own 30 
personal computer. Users are also allowed to convert to 
new releases at their own pace. 

This approach to performing releases fulfills initial 
requirements: 

(1). All files in the release have been moved to the 35 
release directory. These files are mutually consistent 
versions of software. All DF files refer to files known to 
be on the release directory. 

(2). As described earlier, we cannot make a configu- 
ration module that contains all the modules in a release. 40 
Cedar releases are composed of (a) a boot file and (b) 
programs that are mutually consistent and can be run on 
a personal machine with the boot file being released. 
Phase two runs VerifyDF on all the components to 
guarantee that the versions of source and object files 45 
listed in the DF file are the ones actually used to build 
the component and guarantees that all files needed to 
build the component are listed in the DF file, so no files 
that conflict in version can be omitted. 

(3). The release process is automatic enough that 50 
frequent releases are possible. Bugs in frequent releases 
are easily reported since the concept of ownership is 
very strongly enforced by our approach. The program- 
mer who provides new versions of software is the recip- 
ient of bug reports of his software. 55 

(4). The Release Master is required to (a) decide 
when to make a release, (b) send a call-for-submissions 
message, (c) make a to-level DF file and run the Release 
Tool, and (d) send a message announcing the release's 
completion. Because releases are expected, over time, to 60 
include more and more system programs, it is important 
that the Release Master not need to compile packages 
other than any packages he may be contributing to the 
release. Indeed, no single person has ever known how 
to compile the entire system by himself. 65 

Since the implementors use DF files for maintaining 
their own software as well as for submitting compo- 
nents to the release, there is little additional burden on 



the implementors when doing a release. If the burden 
were too high, the implementors would delay releases 
and overall progress would be slowed as the feedback 
from users to implementors suffered. 

(5). A general database system to describe the depen- 
dency hierarchy of packages when we are producing 
systems is not needed. A message system is used, rather 
than a database of information that the programmers 
can query, to notify implementors that packages they 
may depend on are ready. 

Many aspects of bootstrapping Cedar are simplified 
when interfaces to the lowest and most heavily used 
parts of the boot file are not changed. Some major re- 
leases use the same versions of interfaces to the system 
object allocator and fundamental string manipulation 
primitives. Most major releases use the same versions of 
interfaces to the underlying Pilot system such as the file 
system and process machinery. The implementations of 
these stable parts of the system may be changed in ways 
that do not require interface changes. 

In the Cedar environment, two previous releases 
have included changes to the interfaces of the operating 
system, called Pilot and discussed in the Article of Re- 
dell et al. "Pilot: An Operating System for a Personal 
Computer", Proceedings of the Seventh Symposium on 
Operating System Principles, December 1979, and 
thereby forced changes in the style of integration for 
those releases. Since the released loader cannot load 
modules that refer to the new versions of operating 
system interfaces, the software of Cedar environment 
that is preloaded in the boot file must all be recompiled 
before any changes can be tested. Highest priority is 
given to producing a boot file in which these changes 
can be tested. 

If the DF files describing the Cedar system were 
layered in hierarchical order, with the operating system 
at the bottom, this boot file could be built by producing 
new versions of the software in each DF file in DF- 
dependency order. FIG. 9 shows the dependency graph 
for DF files in the boot file, where an arrow from one 
DF file, e.g., Rigging.DF, to another, e.g., Cedar- 
Reals.DF, indicates Rigging.DF IMPORTS some 
file(s) from CedarReals.DF. In this dependency graph, 
"tail" DF files depend on "head" DF files, Double 
headed arrows indicate mutual dependency. Basic 
Heads. DF means that this DF file includes other files, 
BasicHeadsDorado.DF, BasicHeadsDO.DF and Basi- 
cHeadCommon.DF, Communication.DF includes 
CommunicationPublic.DF, Communication- 

Friends.DF and RS232Interfaces.DF. Com- 
patabilityPackage.DF includes MesaBAsics.DF. 

Note that Rigging.DF also depends on Com- 
patibilityPackage.DF, but the dependency by Cedar- 
Reals.DF on CompatibilityPackage.DF ensures a new 
version of Rigging.DF will be made after both lower 
DF files. The Pilotlnterfaces.DF file is at the bottom 
and must be changed before any other DF files. 

This dependency graph is not acrylic, however. The 
most extreme cycle is in the box with six DF files in it, 
which is expanded in FIG. 10. Each DF file is in a cycle 
with at least one other DF file, so each DF file depends 
on the other, and possibly indirectly, and no DF file can 
be announced "first". There is an ordering in which 
these component can be built: If the interfaces listed in 
each of the DF files are compiled and DF files contain- 
ing those interfaces are stored on <PreCedar>, each 
programmer can then compile the implementation mod- 
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ules in this component and then store the remaining files 
on <PreCedar>. 

An example for the dependency graph for interfaces 
is shown in FIG. 11. This graph indicates that the inter- 
faces of CIFS, VersionMap, Runtime, WorldVM, List- 5 
sAndAtoms, and lO can be compiled in that order. This 
interface dependency graph had cycles in it in the 
Cedar release that have since been eliminated. Appen- 
dix A contains examaples of some of these DF files 
before and after the release. 10 

Recompilation of all the interfaces in the boot file 
requires that at least nine programmer/xisers partici- 
pate. Since the boot file cannot be produced until all 
interfaces and implementation modules in the DF files 
of FIG. 9 are compiled, interface changes are encour- 15 
aged to be made as soon as possible after a successful 
release and only once per release. Once the users have 
made their interface changes and a boot file using the 
new interfaces is built, the normal period of testing can 
occur and new changes to implementation modules can 20 
be made relatively painlessly. 

Components being released that are outside the boot 
file have a much simpler dependency structure, shown 
in FIG. 12. The majority of these components are appli- 
cation programs that use Cedar system facilities already 25 
loaded in the boot file. 

The information in the DF files of a release help to 
permit study and planning for the development of the 
Cedar system. The ability to scan, or query, the inter- 
connection information gives a complete view of the 30 
use of software by other programs in the system. For 
example, one can mechanically scan the DF files of an 
entire release and build a dependency graph describing 
the interfaces used in Cedar and which implementors 
depend on these interfaces. Since VerifyDF ensures all 35 
interfaces needed by a component are described in its 
DF file, an accurate database of information can be 
assured. This information can be used to evaluate the 
magnitude of changes and anticipate which components 
can be affected. One can also determine which inter- 40 
faces are no longer used, and plan to eliminate the im- 
plementation of those interfaces, which happens often 
in a large programming environment while it is under 
active development. 

The Cedar release/DF approach assumes only one 45 
person is changing a DF file at a time. How would we 
cope with more than one modifier of a package? If the 
package is easily divided, as with the Cedar system 
window manager and editor, two or more DF files can 
be included by an "umbrella" DF file that is released. 50 
One of the implementors must "own" the umbrella DF 
file and must make sure that the versions included are 
consistent by running VerifyDF check on the umbrella 
file. If the package is not easily divided, then either a 
check in/check out facility must be used on the DF and 55 
its contents to guarantee only one person is making 
changes at a time, or a merge facility would be needed 
to incorporate mutually exclusive changes. Should 
more than one programmer change the same module, 
this merge facility would have to ask for advice on 60 
which of the new versions, if any, to include on the DF 
file. 2. Module Interconnection Language — SML 

SML is a polymorphic and applicative language that 
is used to describe packages of Cedar modules. The 
programmer/user writes SML programs, which are 65 
called system models, to specify the modules in the 
system the user is responsible for and the interconnec- 
tions between them. These system models are analyzed 



by a system modeller of the instant invention that auto- 
mates the compile-edit-debug cycle by tracking changes 
to modules and performs the compilation and loading of 
systems. 

The specification of module interconnection facilities 
of the Cedar system requires use of polymorphism, 
where the specification can compute a value that is later 
used as the type for another value. This kind of poly- 
morphism is explained in detail later. The desire to have 
a crisp specification of the language and its use of poly- 
morphism led to base SML on the Cedar Kemal lan- 
guage, which is used to describe the semantics of Cedar 
developed programs. 

The semantics of the SML language have to be unam- 
biguous so every syntactically-valid system model has 
clear meaning. The Cedar Kemal language has a small 
set of principles and is easily implemented. The clear 
semantics of Kermel language descriptions give a con- 
cise specification of the SML language and give good 
support to the needs of the module interconnection 
specification. SML could have been designed without 
reference to the Kemal language. However, without 
the Kernel language as a base, there would be less confi- 
dence that all language forms had clear meaning. 

SML is an applicative language, since it has no assign- 
ment statement. Names or identifiers in SML are given 
values once, when the names are declared and the value 
of a name may not be changed later unless the name is 
declared in some inner scope. SML is easier to imple- 
ment because it is applicative and function invocation 
has no side effects. 

The fundamental concepts of SML are now pres- 
ented, followed by a description of SML's treatment of 
files. The Cedar Kemal language, which serves as a 
basis for SML, is described, followed by a section on the 
syntax and semantics of SML expressions. 

The Cedar System is based on the Mesa language see 
Mitchell et al., supra and Lauer et al., supra. The system 
contains features for automatic storage management 
(garbage collection) and allows binding of types at run- 
time, i.e. pointers to objects whose types are known 
only at runtime. The system derives from the Mesa 
language a rich module interconnection structure that 
provides information hiding and strong type checking 
at the module level, rather than at the procedure level. 
In order to better understand SML, it is important to 
know about the existing module interconnection facili- 
ties used in the Cedar system. 

As previously indicated in part, a Cedar system con- 
sists of a set of modules, each of which is stored in a 
separate file. A module can be one of two types: an 
implementation (PROGRAM) module, or an interface 
(DEFINITIONS) module. Interface modules contain 
constants found in other Pascal-like languages: proce- 
dure declarations, type declarations, and other vari- 
ables. A module that wishes to call a procedure de- 
clared in another module must do so by IMPORTing an 
interface module that declares this procedure. This 
interface module must be EXPORTED by a PRO- 
GRAM module. For example, a procedure "USortList" 
declared in a module "Sortlmpl" would also be de- 
clared in an interface Sort, and Sortlmpl would EX- 
PORT Sort. A PROGRAM that wants to call the pro- 
cedure USortList does so by IMPORTing Sort. We call 
the importer of Sort the "client" module and say Sor- 
tlmpl (the exporter) "implements" Sort. Of course, 
Sortlmpl may IMPORT interfaces to use that are de- 
fined elsewhere. 
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These interconnections are shown in FIG. 13, which 
shows filenames for each module in the upper left cor- 
ner. The interface Sort defines an object composed of a 
pair of x,y coordinates. The EXPORTer, Sortlmpl- 
.Mesa, declares a procedure that takes a list of these 5 
objects and sorts them, eliminating duplicates. LIST in 
the Cedar system is a built-in type with a structure 
similar to a Lisp list. Clientlmpl.Mesa defines a proce- 
dure that calls USortList to sort a list of such objects. 
Details about "CompareProc" have been omitted for 10 
simplicity. 

Most collections of modules in the system use the 
same version of interfaces, e.g., there is usually only one 
version of the interface for the BTree package in a 
given system. Situations arise when more than one ver- 15 
sion is used in a system. For example, there could be 
two versions of an interface to a list manipulation sys- 
tem, each one manipulating a different type of object. 

FIG. 14 shows, on the left, the module from FIG. 13 
and, on the right, another similar module that defines an 20 
"Object" to be a string instead of coordinates. A module 
that refers to the Sort interface would have to be com- 
piled with one of the two versions of the Sort interface, 
since the compiler checks types of the objects being 
assembled for the sort. This is referred to as interface 25 
type parameterization since the types of items from the 
interface used by a client (Clientlmpl.Mesa) are deter- 
mined by the specific version of the interface (Sort- 
Coord.Mesa or SortNames.Mesa). 

A different kind of parameterization may occur when 30 
two different implementations for the same interface are 
used. For example, a package that uses the left version 
of the Sort interface in FIG. 14 above might use two 
different versions of the module that EXPORTS Sort, 
one of which uses the Quicksort algorithm and the ^5 
other uses the HeapSort algorithm to perform the sort. 
Such a package includes both implementors of Sort and 
must specify which sort routine the clients (IMPORT- 
ers) use when they call Sort.USortListQ. In the Cedar 
system, it is possible for a client module to IMPORT *0 
both versions, as shown in FIG. 15. 

In FIG. 15, SortQuicklmpl and SortHeapImpl both 
EXPORT different procedures for the Sort interface. 
One procedure, SortQuicklmpl, uses Quicksort to sort 
the list. The other uses HeapSort to sort the list. The *5 
importer, Clientlmpl, IMPORTS each version under a 
dififerent name. SortQuicklnst and SortHeapInst are 
called interface records, since they are represented as 
records containing pointers to procedures. The client 
procedure "TestThem" calls each in turn by specifying 50 
the name of the interface and the name of the proce- 
dure, e.g., SortQuicklnst.USortListQ. 

How are the two interface records that are EX- 
PORTED by SortQuicklmpl and SortHeapImpl con- 
nected to the two interface records (SortQuicklnst and 55 
SortHeapIInst) required by Clientlmpl? A program 
called the Mesa Binder makes these connections by 
reading a specification written in a subset of Mesa called 
C/Mesa. C/Mesa source files, called CONFIGURA- 
TIONS, name the implementation modules involved *0 
and specify the interconnections. Below is shown the 
configuration that makes this connection: 



ClientConfig: CONFIGURATION 
SQl: Sort <- SortQuickImpl[]; 
SHI: Sort ■•- SorlHeaplmplQ; 
CUentImpl[SortQuicklnst: SQl, 
SortHeapInst: SHI]; 



{ 
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}. 



Two variables are declared (SQl and SHI) that corre- 
spond to the interface records EXPORTED by the two 
modules. The client module is named, followed by the 
two interfaces given in keywork parameter notation. 

This is called interface record parameterization, since 
the behavior of the client module is a function of which 
interfaces SortQuicklnst and SortHeapInst refer to 
when they are called in Clientlmpl. 

C/Mesa, as currently defined, cannot express inter- 
face type parameterization at all. The semantics of some 
C/Mesa specifications are ambiguous. Because of this, 
the use of SML was choosen to replace the use of 
C/Mesa. 

SML programs give the programmer/user the ability 
to express both kinds of parameterization. It is possible 
to think of SML as an extension of C/Mesa, although 
their underlying principles are quite different. Before 
explaining SML, reference is first made to an example 
of modules that use both interface type and interface 
record parameterization and show how this can be ex- 
pressed in SML. 

The essential features of SML are illustrated by the 
following simple model and are discussed later on rela- 
tive to SML's treatment of files. A description of the 
SML language is also given later. 

Consider two versions of the Sort interface from 
FIG. 14 and two EXPORTERS of Sort from FIG. 15. 
Since the EXPORTERS do not depend on the kind of 
object (coordinates or names), the EXPORTERS can 
each be constructed with a different type of object. 
Assume the client module wants to call USortList with 
all four combinations of object type and sort algorithm: 
(coordinates -(-quicksort, coordinates -)- heapsort, na- 
mes -f quicksort, names -hheapsort). FIG. 16 shows a 
version of Clientlmpl module that uses all four combi- 
nations of object type. 

In SML, a model to express this is shown in Table II 
below. 



TABLE II 



ClieiitModel~[ 



interface types 

SortCoord: INTERFACE ~ @SortCoord. MesaQ; 

SortNames: INTERFACE ~ @SortNames.Mesa[]; 

interface records 

SQCI: SortCoord ~@SortOuickImpl.Mesa[SortCoord]; 

SQNI: SortNames ~@SortQuicklinpl.Mesa[SortNames]; 

SHCI: SortCoord ~@SortHeapImpl.Mesa[SortCoord]; 



give all to client 

Client: CONTROL~@Clientlmpl.Mesa 

[SortCoord.SortNames.SQCI, 

SQNI.SHCI.SHNI] 



SML allows names to given types and bound to val- 
ues. After the header, two names "SortCoord" and 
"SortNames" are given values that stand for the two 
versions of the Sort interface. Each has the same type, 
since both are versions of the Sort interface. Their type 
is "INTERFACE Sort", where "INTERFACE" is a 
reserved word in SML and "Sort" is the interface name. 
The next four lines bind four names to interface records 
that correspond to the different sort implementations. 
"SQCI" is a name of type "SortCoord" and has as value 
the interface record with a procedure that uses Quick- 
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Sort on objects with coordinates. Similarly, "SQNI" 
has as value an interface record with a procedure for 
Quicksort on objects with strings, etc. Note that each 
of the four implementations is parameterized by the 
correct interface, indicating which type to use when the 5 
module is compiled. 

The last line specifies a name "Client" of reserved 
type "CONTROL" and gives it as value the source file 
for Clientlmpl, parameterized by all the previously 
defined names. The first two, SortCoord and Sort- 10 
Names, are values to use for the names "SortCoord: 
INTERFACE Sort" and "SortNames: INTERFACE 
Sort" in the DIRECTORY clause of Clientlmpl. The 
last four, in order, give interface records for each of the 
four imports. '5 

There are a number of nearly-equal names in the 
example. If all related names were uniform, e.g., Sort- 
QuickCoordlmpl instead of SQHI and SortQuickCoor- 
dlnst, and SortHeapCoordlmpl instead of SQHI and 
SortHeapCoordlnst, then the parameter lists in the ex- 20 
ample could be omitted. 

The kinds of values in SML follow naturally from the 
objects being represented: the value of "@ SortCoord- 
.MesaQ" is the object file for the interface module Sort- 
Coord.Mesa when it is compiled. The value of "@ ^^ 
SortQuicklmpI.MesaQ" is an interface record produced 
when the object file for SortQuicklmpl.Mesa is loaded. 
Note there are two versions of the object file for Sort- 
Quicklmpl.Mesa: one has been compiled with Sort- 
Coord as the interface it EXPORTS, and the other has ^ 
been compiled with SortNames as the interface it EX- 
PORTS. 

It is helpful to differentiate the two types of parame- 
terization by the difference in uses: Interface type pa- 
rameterization is applied when a module is compiled 
and the types of the various objects and procedures are 
checked for equality. Interface record parameterization 
is applied when a module is loaded and the imports of 
other modules are resolved. The interface records by 
which a module is parameterized are used to satisfy 
these inter-module references. 

The SML language is built around four concepts: 

1. Application: The basic method of computing. 

2. Values: Everything is a value, including types 
(polymorphism) and functions. 

3. Binding: Correspondence between names and val- 
ues is made by binding. 

4. Groups: Objects can be grouped together. 

Application 50 

The basic method of computation in the SML lan- 
guage is by applying a function to argument values. A 
function is a mapping from argument values to result 
values. 

A function is implemented either by a primitive sup- 
plied by the language (whose inner workings are not 
open to inspection) or by a closure, which is the value of 
a X.-expression whose body, in turn, consists of applica- 
tions of functions to arguments. In SML, X-expressions ^ 
have the form 

\[free- vari able-list]— (returns-li5t]IN[body-expres- 
sion] 

For example, a \-expression could look like °' 

\[x: STRING, y: STRINGMa: STRING]IN[exp] 
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where "x" and "y" are the free variables in the X-ex- 
pression, "a" is the name of the value returned when 
this X-expression is invoked, and exp is any SML expres- 
sion that computes a value for name "a". "IN" is like "." 
in standard X-notation. It is helpful to think of a closure 
as a program fragment that includes all values necessary 
for execution except the X*s parameters, hence the term 
closure. Every X-expression must return values, since 
the language has no side effects. Application is denoted 
in programs by expressions of the form /[arg, arg, . . . ]. 

A SML program manipulates values. Anything that 
can be denoted by a name or expression in the program 
is a value. Thus strings, functions, interfaces, and types 
are all values. In the SML language, all values are 
treated uniformly, in the sense that any can be passed as 
an argument, bound to a name, or returned as a result. 

These operations must work on all values so that 
application can be used as the basis for computation and 
X-expressions as the basis for program structure. In 
addition, each particular kind or type of value has its 
own primitive functions. Some of these (like equality) 
are defined for most types. Others (like subscripting) 
exist only for specific types (like groups). None of these 
operations, however, is fundamental to the language. 

There is a basic mechanism for making a composite 
value out of several simpler ones. Such a composite 
value is called a group, and the simpler ones are its 
components or elements. Thus [3, x-l-1, "Hello"] de- 
notes a group, with components 3, x-f 1, and "Hello". 
The main use of groups is for passing arguments to 
functions without naming them. These are sometimes 
called positional arguments. Groups are similar to other 
language's "structures" or "records": ordered and 
typed sequences of values. 

A binding is an ordered set of [name, type, value] 
triples, often denoted by a constructor like the follow- 
ing: [x: STRING ~"s", y: STRING ~"t"], or simply 
[x~"s", y~"t"]. Individual components can be se- 
lected from a binding using the "." operation, similar to 
Pascal record selection: binding.element yields the 
value of the component named "element" in binding. 

A scope is a region of the program in which the value 
bound to a name does not change. For each scope there 
is a binding that determines these values. A new scope 
is introduced by a [. . . ] constructor for a declaration or 
binding, or a LET statement illustrated below. 

A declaration is an ordered set of [name, type] pairs, 
often denoted [x: STRING, y: STRING]. A declaration 
can be instantiated (e.g. on block entry) to produce a 
binding in which each name is bound to a name of the 
proper type. If d is a declaration, a binding b has type d 
if it has the same names, and for each name n the value 
b.n. has the type d.n. 

In addition to the scopes defined by nested bindings, 
a binding can be added to the scope using a LET state- 
ment, 

LET binding IN expr 

that makes the names in binding accessible in expr with- 
out qualification. 

Every name has a type, either because the name is in 
a binding or the name is in a declaration. Names are 
given values using bindings. If a name is given an ex- 
plicit type in the binding, the resulting value must have 
that type. For example. 
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the type of "v' 
pression with ' 
then 

P(b] 



' must be "t". Similarly, if "p" is a X-ex- 
'a" as a free variable of type "STRING", 



type-checks if "b" has type "STRING". 

There are no restrictions on use of typye as values in 
SML. For example, 



[ni: t ~ vl, 
n2: nl ~ v2] 



declares a name "nl" with a type t and a value vl, and 
then declares a name "n2" with type "nl" and value 
"v2". Although each such value can in turn be used as 
the type of another name, the modeller implementation 
does not attach semantics to all such combinations. 

Strings are useful in a module interconnection lan- 
guage for compiler options and as components of file 
names. SML contains facilities to declare strings. For 
example, the binding 



[x: STRING 
y; STRING 



"lit", 



gives X and y the string literal value "lit". 

SML describes software by specifying a file contain- 
ing data. This file is named in SML by a filename 
preceded by an @. SML defines @ as source-file inclu- 
sion: The semantics of an ©-expression are idential to 
those of an SML program that replaced the @ expres- 
sion by its contents. For example, if the file inner.sm 
contained 



"lit" 



which is a valid SML expression, the binding 



[x: 


STRING 


^ 


@inner.sm, 


y: 


STRING 


~ 


©inner.sm] 


and 






(x: 


STRING 


~ 


"lit", 


y: 


STRING 


~ 


"lit"] 
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The ©-expression is used in SML to refer to source 
modules. Although we cannot substitute the @-expres- 50 
sion by the contents of the source file since it is written 
in C/Cedar, we treat the Cedar source file as a value in 
the language with a type. This type is almost always a 
procedure type. The values in SML that describe mod- 
ule interconnection are all obtained by invoking one of 55 
the procedure values defined by an ©-expression. 

When compiUng a system module, all interfaces it 
depends on must be compiled first and the compiler 
must be given unambiguous references to those files. In 
order to load a module, all imports must be satisfied by 60 
filling in indirect pointers used by the microcode with 
references to procedure descriptors EXPORTed by 
other modules. Both kinds of information are described 
in SML by requiring that the user declare objects corre- 
sponding to an interface file (for compilation) or an 65 
interface record with procedure descriptors (for load- 
ing), and then parameterize module objects in SML as 
appropriate. 



Consider an interface that depends on no other inter- 
faces, i.e., it can be compiled without reference to any 
files. SML treats the file containing the interface as a 
function whose closure is stored in the file. The proce- 
dure type of this interface is for a procedure that takes 
no parameters and returns one result, e.g., 

D->[INTERFACE Sort] 

where "Sort" is the name of the interface, as in FIG. 13. 
The application of this \-expression (with no argu- 
ments) will result in an object of type "INTERFACE 
Mod". 

Id: INTERFACE Sort~@ Sort.MesaQ 

declares a variable "Id" that can be used for subsequent 
dependencies in other files. An interface "BTree" de- 
fined in the file "BTree.Mesa" that depends on an inter- 
face named "Sort" would have a procedure type like: 

[INTERFACE Sort]— [INTERFACE BTree] 

The parameters and results are normally given the same 
name as the interface type they are declared with, so the 
procedure type would be: 

[Sort: INTERFACE Sort]— [BTree: INTERFACE 
BTree] 

In order to express this in his model, the user would 
apply the file object to an argument list: 

Sort: INTERFACE Sort~@ Scrt.MesaO; 

BTree: INTERFACE BTree ~@ 
BTree.Mesa[Sort]; 

These interfaces can be used to reflect other compila- 
tion dependencies. 

An interface that is EXPORTed is represented as an 
interface record that contains procedure descriptors, 
etc. These procedures are declared both in the interface 
being EXPORTed and in the exporting PROGRAM 
module. One can think of the interface record as an 
instance of a record declared by the interface module. 
Consider the implementation module Sortlmpl.Mesa in 
FIG. 13. Sortlmpl EXPORTS an interface record for 
the Sort interface and calls no procedures in other Sor- 
tlmpl EXPORTS an interface record for the Sort inter- 
face and calls no procedures in other modules (i.e., has 
no imports). This file would have as procedure type: 

[Sort: INTERFACE Sort)— [Sortlnst: Sort] 

and would be used as follows: 

Sort: INTERFACE Sorl~@ Sort.MesaQ; 
Sortlnst: Sort~@ SortImpl.Mesa[Sort]; 

which declares an identifier "Sortlnst" of the type 
"Sort", whose value is the interface record exported by 
Sortlmpl.Mesa. If Sortlmpl.Mesa imported an interface 
reocrd for "BTree," then the procedure type would be: 

[Sort: INTERACE Sort, BTree: INTERFACE 
BTree. BTreelnst: BTree]— [Sortlnst: Sort] 

and the exported record would be computed by: 



Sortlnst: Sort~( 
BTreelnst): 
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where [Sort, BTree, BTreelnstr] is a group that is 
matched to parameters of the procedure by position. 
Keyword matching of actuals to formals can be accom- 
plished through a binding described later. 

LET statements are useful for including defmitions 
from other SML files. A set of standard Cedar inter- 
faces could be defined in the file CedarDefs.Model: 



[ 



Rope: INTERFACE Rope ~ @Rope.Mesa, 

lO: INTERFACE lO ~ @IO.Mesa, 

Space: I>rrERFACE Space - ©Space.Mesa 



Then a LET statement like: 

LET @ Cedar Defs.Model IN [expression] 



is equal to: 



LET[ 




Rope: INTERFACE Rope - 


- @Rope.Mesa, 


lO: INTERFACE lO - @IO.Mesa 


Space: INTERFACE Space 


~ @Space.Mesa 


]IN [expression] 





and makes the identifiers "Rope", "lO", and "Scope" 
available within [expression]. 

SML syntax is described by the BNF grammar be- 
low. Whenever "x, ..." appears, it refers to or more 
occurrences of x separated by commas. " | " separates 
different productions for the same non-terminal. Words 
in which all letters are capitalized are reserved key- 
words. Words that are all lower case are non-terminals, 
except for 

id, which stands for an identifier, 

string, which stands for a string Uteral in quotes, and 

filename, which stands for a string of characters that 
are legal in a file name, not surrounded by quotes. 

Subscripts are used to identify specific non-terminals, 
so they can be referenced without ambiguity in the 
accompanying explanation. 



exp :: = 1 [decli] — » [decli] IN expi 

I let [binding] IN expi 

|expi-.exp2 

|expi[exp2] 

jexpi . id 

i[exp, ...] 

|[decl] 

{ [binding] 

lid 

{ string 

I l?«JTERFACE id 

I STRING 

I @niename 
deci :; = id; exp, . . . 
binding :: = bindelem, . . . 
bindelem :: = [decl] ~ expi 

j id: expi ~~ CJ1P2 

I id ~ expi 
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A model is evaluated by running a Lisp-style evalua- 
tor on it. This evaluator analyzes each construct and 65 
reduces it to a minimal form, where all applications of 
closures to known values have been replaced by the 
result of the applications using yS-reduction. The evalua- 



tor saves partial values to make subsequent compilation 
and loading easier. The evaluator returns a single value, 
which is the value of the model, usually a binding. 
The semantics for the productions are: 

exp:: = X[decli)— >[decl2]lN eipi 

The expression is a value consisting of the parameters 
and returned names, and the closure consisting of the 
expression expi and the bindings that are accessible 
statically from exp. The type is "decli->decl2". The 
value of this expression is similar to a procedure vari- 
able in conventional languages, which can be given to 
other procedures that call it within their own contexts. 
The closure is included with the value of this expression 
so that, when the A.-expression is invoked, the body 
(expi) will be evaluated in the corect environment or 
context. 

exp:: = LET [binding]IN expi 

The current environment of expi is modified by add- 
ing the names in the binding to the scope of expi. The 
type and value of this expression are the type and value 
of expi. 

exp::=expi— ^xp2 

The value of exp is a function type that takes values 
of type expi and returns values of type exp2. 

exp::=expi[exp2l 

The value of expi, which must be a closure, is applied 
to the argument list expj as follows. A binding is made 
for the values of the free variables in the \-expression. If 
exp2 is a group, then the components of the group are 
matched by type to the formals of the X-expression. The 
group's components must have unique types for this 
option. If exp2 is a binding then the parameters are given 
values using the normal binding rules to bind f~exp2 
where exp2 is a binding and f is the decl of the X-expres- 
sion. 

There are two cases to consider: 

1. The X-expression has a closure composed of SML 
expressions. This is treated like a nested function. The 
evaluation is done by substitution or j3-reduction: All 
occurrences of the parameters are replaced by their 
values. The resulting closure is then evaluated to pro- 
duce a result binding. The X-expression returns clause is 
used to form a binding on only those values listed in the 
X-expression returns list, and that binding is the value of 
the function call. 

2. If the function being applied is a Cedar source or 
object file, the evaluator constructs interface types of 
interface records that correspond to the interface mod- 
ule or to the implementation module's exported inter- 
faces, as appropriate. After the function is evaluated, 
the evaluator constructs a binding between the returned 
types in its procedure type and the values of the func- 
tion call. 

exp:: = [exp, . . . ] 

The expi is evaluated and must be a binding. The 
component with name "id" is extracted and its value 
returned. This is ordinary Pascal record element selec- 
tion. 
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ej(p:: = [exp, . . . ] 



A group of the values of the component exp's is made 
and returned as a value. 5 

ejip:: = [decl] 
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then p takes two parameter, which may be specified as 
a group: 



defs: INTEFACE Y ~ ©Defs.MesaQ, 
z: INTERFACE Z ~ p["lit", Defs) 



decl;: — id:exp, . . . 

Adds names "id" to the current scope with type equal 
to value of exp. A list of decls is a fundamental object. 



exp :: = [binding] 
binding :: = bindelem, 
bindelem ;: = [decl] ~ 

I id: expi ~ expi 

I id ~ expi 



10 



where the arguments are matched by type to the param- 
eters of the closure. The order of "lit" and Defs in the 
example above does not matter. Also the order of x and 
y in the call of p in the example does not matter. The 
function may also be called with a binding as follows: 



15 



20 



A bindelem binds the names in decl to the value of 
expl. If an id is given instead of a decl, the type of id is 
inferred from that of expi. The binding between the 
names in decl and the values in expi follows the same 
rules as those for binding arguments to parameters of 25 
functions. 

exp:: = id 

id stands for an identifier in some binding (i.e., in an 30 
enclosing scope). The value or id is its current binding. 

exp::=string 



defs: INTERFACE Y ~ @Defs,MesaD, 

z: INTERFACE Z ~ p[x ~ "lit", y ~ Defs] 



which corresponds to keyword notation in other pro- 
gramming languages. 

Since the parameter lists for Cedar modules are quite 
long, the SML language includes defaulting rules that 
allow the programmer to omit many parameters. When 
a parameter list, either a group or a binding, has too few 
elements, the given parameters are matched to the for- 
mal parameters and any formals not matched are given 
default values. The value for each defaulted formal 
parameter is the value of a variable defined in some 
scope enclosing the call with the ame name and type as 
the formal. Therefore, the binding for Z in: 



A string literal like 
the language. 



'abc" is a fundamental value in 35 



exp:: = INTERFACE id 

This fundamental type can be used as the type of any 

. module with module name id. Note id is used as a literal, 

not an identifier, and its current binding is irrelevant. 

The value of this expression is the atom that represents 

"INTERFACE id". 

exp:: = STRING 

A fundamental type in the language. The value of 
"STRING" is the atom that represents string types. 

exp::~@ filename 

This expression denotes an object whose value is 
stored in file filename. If the file is another model, then 
the string @ filename can be replaced by the content of 
the file. If it is another file, such as a source or object 
file, it stands for a fundamental object for which the 
evauator must be able to compute a procedure type. 

Function calls in SML are made by applying a clo- 
sure to (1) a group or (2) a binding. If the argument is a 
group, the parameters of the closure are matched to the 
components by type, which must be unique. If the argu- 
ment is a binding, the parameters of the closure are 
matched by name with the free variables. For example, 
if p is bound to: 

p~X[x: STRING, y: INTERFACE YJ— [Z: 
INTERFACE Z]IN[ . .. ] 
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[ 

x: STRING ~ "lit", 

y: INTERFACE Y ~ @Defs.MesaO, 

z: INTERFACE Z ~ pO 

1 



is equivalent to "p[x. y]" by the equal-name defaulting 
rule. 

SML also allows projections of closures into new 
closures with parameter. For example, 



45 



[ 

Y: INTERFACE Y ~ ©Defs.MeaQ, 

pl:[Y: INTERFACE Y) .- [Z: INTERFACE Z] ~ p{"lit"], 

Z: INTERFACE Z ~ plfY] 



50 



sets Z to the same value as before but does it in one extra 
step by creating a procedure value with one fewer free 
variable, and then applied the procedure value to a 
value for the remaining free variable. The defaulting 
rules allow parameter to be omitted when mixed with 
projections: 
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[ 

X: STRING ~ "lit", 

Y: INTERFACE Y ~ @Defs.MesaD, 

pi: [Y: INTERFACE Y] — [Z: INTERFACE Z] ~ pQ, 

Z: INTERFACE Z ~ plO 



65 



Enough parameters are defaulted to produce a value 
with the same type as the target type of the binding (the 
type on the left side of the notation, " ~ "). When the 
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type on the left side is omitted, the semantics of SML tion, scope printer", where the scope pointer is used to 

guarantee that all parameters are defaulted in order to establish the naming environment for variables inside 

produce result values rather than a projection. Thus the body that are not formal parameter. The ©-expres- 
sion is represented by an object that contains a pointer 

Z~piD 5 to the disk file named. A variable declared as I>rTER- 

FACE mod (i.e., an interface type variable), is repre- 

in the preceding examples declares a value Z of type ^^^^^ ^ ^ "module name, pointer to module file" pair, 

INTERFACE Z and not a projection whose value is a ^ ^ ^ variable given as type and interface type variable, 

X-expression. These rules are stated more concisely j^^ ^ interface record variable, is repreented as a 

"^'°^' „ . . , , '" "pointer to procedure descriptors, pointer to loaded 

If the number of components is less than those re- module" 

quired to evaluate the function body a coercion is ap- ^^ substitution property of Russell, discussed in the 

phed to produce either (1) the complete argument ist. ^^.^j^ ^^ ^ ^^^^^^ ^^ ..^^^^ Parameters & 

so the function body may be evaluated, or (2) a projec- checking", Proceedings of the Seventh Sympo- 

tionoftheonginalX-expressionintoanewX-expression ,c ^>F'= '-""''^"s c -a t i „- 

■-t. r c ■ tX Tf »i, . , « „<■ ►!,« ™...i* „f Slum on Pnnciples of Programming Languages, Las 

with fewer free variables. If the type of the result of ^ = „,„„.«™ »r„, ^„..i„Ki» 

„ . ,„ . ... . /i\ „, /i\ ...iu u^ „„ Vegas, Nev., pp. 12-23, 1980, guarantees that vanable- 

expi[exp2] IS supplied, one of (1) or (2) will be per- ''<»^' .' *^»^ u i ? i. *i. ■ i -.t. » 

r^^li wi^„ tt,/fl,„ot t„r.» ic r,^ m,,»n ^ » ^ee exprcssioHS can be replaced by their values without 

formed. When the target type is not given, e.g., , . ^. ^- rn n _ c- ex*T 

altenng the semantics of Russell programs. Since SML 

x~proc[Y] programs have no variables and allow no recursion, the 

^^ substitution property holds for SML programs as well. 

case (1) is assumed and all parameters of "proc" are This implies that the type-equivalence algorithm for 

assumed defaulted. For example, the expression: SML programs always terminates, since the value of 

each type can always be determined statically. 

proc: [Y: STRING, Z: STRiNOMr: R], The following are two further examples of models 

^^ described in SML. 

x:T~proc[Y] 

EXAMPLE 1 

binds the result of applying proc to Y to x of type T. If yj^^ ^_^^^ package consists of an implementation 

T is a simple type (e.g., "STRING"), then the proc[Y] module in the file "BTreelmpl.Mesa" and an interface 

expression is coerced into proc[YU, Z], where Z is the 30 "BTree.Mesa" that BTreelmpl EXPORTS. There is no 

name of the omitted formal m the X-expression and R ^y^^, ^f ^jf^e, so this model returns a value for the 

must equal T. If Z is undefined (has no bindmg) an error interface type and record for BTree. Some other model 

has occurred and the result of the expression is unde- contains a reference to this model and a client for that 

fined. If T is a function type (e.g., [Z: STRING]-.[r: interface. The BTree interface uses some constants 

R]), then a new closure is replaced by tghe value of Y 35 ^^^^^ ^^ "Ascii.Mesa", which contains names for the 

This closure may be subsequently apphedto a value of ^gj.jj chaacter set. The BTreelmpl module depends 

Z and the result value can be computed. The type of Z ^^ ^^ ^^^^ interface since it EXPORTs it and makes 

must agree with the parameters of the target function ^ ^j. ^j^^^^ standard Cedar interfaces. "Rope" defines 

*^^' ^^M^ , ■ .. jj J • ..« procedures to operate on immutable, garbage collected 

The SML evaluator is embedded m a program man- 40 ^^ ..j^.. ./^ ^^^^^^ ,^^^ ^^^^^ procedures to 

agement system that separates the functions of file re- ^^"^^ ^^te formatted data to a stream, often the 

tneval compilation, and loading of modules. Each of ^^,^ computer terminal. "Space" defines procedures 

these functions is implemented by analyzing the partial ^^ allocate Cedar virtual memory for large objects, in 

values of the evaluated SML expression. For example, ^^^ ^j^^ ^^^^ 

the application of a file to arguments is analyzed to see 45 f e • 

whether compilation or loading is required. For each of 

these phases, the evaluator could be invoked on the _ Exl.Model 

initial SML expression, but this would be inefficient. LET[ 

Since the SML language has no iteration constructs and ^°P^ ^^^^^Bfo'°^lO^^^^' 

no recursively-defined functions, the evaluator can sub- 50 spac'e^OTERFACE s~p»fe ~ @Space.Bed, 

stitute indirect references to SML expressions through j jn 

©-expressions by the file's contents and can expand BTreePrcx; ~ 

each function by its defining expression with formals x[Ropeinst: Rope. ioisnt:]0, Spaceinst: Space] 

replaced by actuals. -.[BTree: interface BTree. BTreelnst. BTree] 

This process of substitution must be applied recur- 55 ^^^.j;. interface Ascii ~ @Ascii.Mesa 

sively, as the expansion of a X-expression may involve BTree: INTERFACE BTree ~ @Btree[Ascii], 

expansion of inner X-expressionS. The evaluator does BTreelnst: BTree ~]@BTreelmpl.Mesa(BTree, Rope.]O.Space, 

this expansion by copying the body of the X-expression, Ropelmt, loinst. Spaceinst] 

and then evaluating it using the scope in which the .! — — 

X-expression was defined after adding the actual param- 60 

eters as a binding for the function to the scope. This model, stored in the file "Exl.Model", describes 

The scope is maintained as a tree of bindings in which a BTree system composed of an interface "BTree" and 

each level corresponds to a level of binding, a binding an implementation for it. The first three lines declare 

added by a LET statement, or a binding for parameters three names used later. Since they are given values that 

to a X-expression. 65 are object or binary (.bed) files, they take no parame- 

Bindings are represented as lists of triples of name, ters. This model assumes those files have already been 

type, value. A closure is represented as a quadruple compiled. Note they could appear as: 
comprising "list of formals, list of returns, body of func- 
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Rope ~ @Rope. Bed, 

IO~@IO.Bed, 

Space~@Space.Bcd 

since the types of the three identifiers can be determined 
from their values. The seventh line binds an identifier 
"BTreeProc" to a ^-expression with three interface 
records as parameters. If those are supplied, the func- 
tion will return (1) an interface type for the BTree sys- 
tem, and (2) an interface record that has that type. 
Within the body of the closure of the X.-expression, 
there are bindings for the identifiers "Ascii", "BTree", 
and "BTreelnst". In all cases, the type could be omitted 
as well. 

The file "Exl.Model" can be evaluated. Its value will 
be a binding of BTreeProc to a procedure value. The 
value is a X-expression that must be applied to an argu- 
ment list to yield its return values. Another model might 20 
refer to the BTree package by: 

[BTree. 

BTreeIiist]~@Exl.Model).BTreeProc[RopeInst, 
lOInst, Spacelnst] 
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- CedarDefs.Model 

[ 

Rope: INTERFACE Rope ~ @Rope.Bed, 

lO: INTERFACE lO ~ ©lO.Bed. 

Space: INTERFACE Space ~ @Space.Bed 

] 

- BTree.Model 

Let @CedarDefs.Model IN[ 
BTreeProc ~ 

X[RopeInst: Rope. I01snt;]0, Spacelnst; Space] 
-> (BTree: INTERFACE BTree. BTreelnst: BTree] 
IN( 

Ascii: INTERFACE Ascii ~ ©Ascii.Mesa. 
BTree; INTERFACE BTree ~ @BTree[Ascii], 
. BTreelnst: BTree ~ @BTreeImpl.Mesa[BTree, Rope,)0, Space, 
RopeInst,]OInst, Spacelnst] 
] 
I 



45 
The prefix part is split into a separate file. The 
BTree.Model file contains (1) a binding that gives a 
name to the binding in CedarDefs. Model, and (2) a 
LET statement that makes the values in CedarDefs.- 
Model accessible in the X-expression of BTree.Model. 50 

Dividing Example 1 into two models Uke this allows 
us to establish standard naming environments, such as a 
model that names the commonlyused Cedar interfaces. 
Programmer/users are free to redefine these names 
with their models if they so desire. 55 

3. System Modeller — Software Version Management 
System 

The System modeller is a complete software develop- 
ment system which uses information stored in a system 60 
model, which describes a software system in the envi- 
ronment, e.g., the Cedar system, by specifying: 

1. The versions of various modules that make up a 
particular software system. 

2. The interconnections between modules, such as 65 
which procedures are used and where they are defined. 

3. Additional information needed to compile and load 
the system. 



4. Hints for locating the modules in a distributed file 
system. 

Under the direction of the user or programmer, the 
modeller performs a variety of operations on the sys- 
tems described by the system models: 

1. It implements the representation of the system by 
source text in a collection of files. 

2. It tracks changes made by the programmer. To do 
this, it is connected to the system editor and is notified 
when files are edited and new versions are created. 

3. It automatically builds an executable version of the 
system, by recompiling and loading the modules. To 
provide fast response, the modeller behaves like an 
incremental complier: only those modules that change 
are analyzed and recompiled. 

4. It provides complete supp)ort for the integration of 
packages as part of a release. 

Thus, the modeller can manage the files of a system as 
they are changing, providing a user interface through 
which the programmer edits, compiles, loads and de- 
bugs changes interactively while developing software. 
The models are automatically updated to refer to the 
changed components. Manual updates of models by the 
programmer are, therefore, not normally necessary. 

The programmer writes a model in SML notation for 
describing how to compose a set of related programs 
from their components. The model refers to a compo- 
nent module of the program by its unique name, inde- 
pendently of the location in the file system where its bits 
are stored. The development of a program can be de- 
scribed by a collection of models, one for each stage in 
the development; certain models define releases. 

As previously indicated, SML has general facilities 
for abstraction. These are of two kinds: 

(1) A model can be organized hierarchially into parts, 
each of which is a set of named sub-parts called a bind- 
ing. Like the names of files in a directory, the names in 
a binding can be used to select any desired part or parts 
of the binding. 

(2) A model can be parameterized, and several differ- 
ent versions can be constructed by supplying different 
arguments for the parameters. This is the way that SML 
caters for planned variation in a program. 

The distributed computing environment means that 
files containing the source text of a module can be 
stored in many places. A file is accessed most efficiently 
if it happens to be on the programmer's own machine or 
computer. Remote files must first be located and then 
retrieved. The modeUer imposes minimal requirements 
on the capabilities of the distributed file system. In fact, 
it requires only that there be a way to enumerate the 
versions of a particular file in a remote directory, and to 
store or retrieve an entire remote file. When possible, it 
caches information about a module, such as its depen- 
dencies on other modules, to avoid retrieving the entire 
module and parsing its text. It also caches the complete 
path names of objects to avoid searches in remote direc- 
tories. 

When invoked, the modeller uses the objects in a 
model to determine which modules need to be recom- 
piled. The modeller will get any files it needs and try to 
put the system together. Since it has unique-ids for all 
the needed sources, it can check to see if they are 
nearby. If not, it can take the path name in the model as 
a hint and, if the file is there, it can be retrieved. The 
modeller may have difficulty retrieving files, but it will 
not retrieve the wrong version. Having retrieved as 
many files as possible, it will compile any source files if 
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necessary, load the resulting binary files, and run the 
program. 

A model normally refers to source files rather than 
the less flexible binary or object files produced by the 
compiler, whose interiface types are already bound. The 5 
system modeller takes the view that these binary files 
are just accelerators, since every binary file can be com- 
piled using the right source files and parameters. The 
model has no entry for a binary file when the source file 
it was compiled from is listed. Such an entry is unneces- '** 
sary since the binary file can always be reconstructed 
from the source. Of course, wholesale recompilation is 
time consuming, so various databases are used to avoid 
unnecessary recompilation. 

Models refer to objects, i.e., source or binary (object) '' 
files or other models, using an @-sign followed by a 
host, directory, and file name, optionally followed by 
version information. In a model, the expression, 



@(Indigo]<Cedar>X.Mesa!(July 25, 1982 I6:10K)9) 



20 



refers to the source version of X.Mesa created on July 
25, 1982 16:10:09 that is stored on file server [Indigo] in 
the directory < Cedar >. The !(...) is not part of the 
file name but is used to specify explicitly which version 25 
of the file is present. The expression, 

@[Indigo] <Cedar > X.Bed!( 1 AB3FBB4«2BD) 

refers to the binary or object version of X.Bcd on [In- 30 
digo]< Cedar >X.Bcd that has a 48-bit version stamp 
"1AB3FBB462BD" (hexadecimal). For cases when the 
user wants the most recently-saved version of X.Mesa 
or X.Bcd, 

35 
@[Indigo] < Cedar > X. MesalH 

refers to the most recently stored version of X.Mesa on 
[Indigo < Cedar >. This "!H" is a form of implicit pa- 
rameterization. If a model containing such a reference is 40 
submitted as part of a software release, this reference to 
the highest version is changed into a reference to a 
specific version. 

The system modeller takes a very conservative ap- 
proach, so the users can be sure there is no confusion on 43 
which versions have been tested and are out in the field 
of the distributed software system. 

What happens, however, when a new version V2 of 
an object is created? In this view, such a version is a 
new object. Any model Mi which refers to the old 50 
object V] continues to do so. However, it is possible to 
create a new model M2 which is identical to Mi except 
that every reference to Vj is replaced by a reference to 
V2. This operation is performed by the modeller and 
called Notice. In this way, the notion that objects are 55 
immutable is reconciled with the fact of evolution. 

With these conventions, a model can incorporate the 
text of an object by using the name of the object. This is 
done in SML expression by writing an object name 
preceded by sign "@". The meaning of an SML expres- 60 
sion containing an ©-expression is defined to be the 
meaning of an expression in which the @ expression is 
replaced by its contents. For example, if the object 
inner.model contains 

65 
"lit" 

which is an SML expression, the binding 



[x:STRING 
y:STRING 



pinner. sm, 

"lit"] 



has identical values for x and y. 

With these conventions, a system model is a stable, 
unambiguous representation for a system. It is easily 
transferred among programmers and file systems. It has 
a readable text representation that can be edited by a 
user at any time. Finally, it is usable by other program 
utilies such as cross-reference programs, debuggers, and 
optimizers that analyze intermodule relationships. 

The modeller uses the creation date of a source object 
as its unique identifier. Thus, an object name might have 
the form BTree.Cedar!(July 22, 1982 2:23:56); in this 
representation the unique identifier follows the "!" char- 
acter. 

For a derived object such as a binary module, the 
modeller uses a 48-bit version stamp which is con- 
structed by hashing the name of the source object, the 
compiler version and switches, and the version stamps 
of any interfaces which are parameters of the compila- 
tion. In this way, derived objects constructed at differ- 
ent times will have the same names, as long as they are 
made in exactly the same way. This property can make 
a considerable difference in the time required to rebuild 
a system when some binary modules must be rebuilt, 
especially if there are other modules which depend on 
the ones being rebuilt. 

It is also possible to use an ambiguous name for an 
object, such as in the form, BTree.cedarlH. This means 
to consider all the objects whose names begin BTree.ce- 
dar, and take the one with the most recent create date. 

As previously explained, Cedar programing consists 
of a set of modules. There is included two kinds of 
modules: implementation (PROGRAM) modules, and 
interface (DEFINITIONS) modules. An interface 
module contains constants (numbers, types, inline pro- 
cedures, etc.) and declarations for values to be supplied 
by an implementation (usually procedures, but also 
types and other values). A module Mi that calls a proce- 
dure in another module M2 must IMPORT an instance 
Inst of an interface I that declares this procedure. Inst 
must be EXPORTED by the PROGRAM module M2. 
For example, a procedure Insert declared in a module 
BTreelmpl would also be declared in an interface 
BTree, and BTreelmpl would EXPORT an instance of 
BTree. A PROGRAM calls Insert by IMPORTing this 
instance of BTree and referring to the Insert component 
of the instance. The IMPORTer of BTree is called the 
client module, and BTreeImp, the EXPORTer, imple- 
ments Btree. Of course BTreelmpl may itself IMPORT 
and uses interfaces that are defined elsewhere. 

FIG. 17 discloses a very simple system model called 
BTree, which defines one interface BTree and one in- 
stance BTreelnst of BTree. 

BTree.model in FIG. 17 refers to two modules, 
BTree.cedar!(Sept. 9, 1982, 13:52:55) and BTreelmpl- 
.cedar!(Jan. 14, 1983 14:44:09). Each is named by a user- 
sensible name (e.g., BTree.cedar), pat of which identi- 
fies the source language as Cedar, and a creation time 
(e.g. !(Sept. 9, 1982, 13:52:55)) to ensure uniqueness. The 
@ indicates that a unique object name follows. Each 
object also has a file location hint, e.g., ([Ivy] < Sch- 
midt >, i.e., file server. Ivy, and the directory, 
Schmidt). 
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BTree.model refers to two other models, Cedar Inter- 
faces.model!(July 25, 1982, 14:03:03) and Cedarlnstan- 
ces.model!(July 25, 1982, 14:10:12). Each of these is a 
binding which gives names to four interface or instance 
modules that are part of the software system. A clause 5 
such as 

LET CedarInterfac«.model IN . . . 

makes the names bound in Cedarlnterfaces (Acii, Rope, jq 
lO, Space) denote the associated values (Ascii.cedar!- 
(July 10, 1982, 12:25:00)0, etc.) in the expression follow- 
ing the IN. 

Models denote dependency by parameterization. 
There are two kinds of dependency: on interfaces, and jj 
on implementations, or instances of the interfaces. Cor- 
respondingly, each source module is viewed as a func- 
tion which takes interface arguments and returns an- 
other function which takes instance argument. Apply- 
ing the first function to its interface arguments is done jq 
by the compiler; applying the resulting second function 
to its instance arguments is done by the loader as it links 
up definitions with uses. 

In the example of FIG. 17, the BTree interface de- 
pends on the Ascii interface from Cedarlnterfaces. 
Since it is an interface, it does not depend on any imple- 
mentations. BTreelmpl depends on a set of interfaces 
which the model does not specify in detail. The "•" in 
front of the first parameter list for BTreelmpl means 
that its arguments are defaulted by name matching from jq 
the system environment. In particular, it probably has 
interface parameters BTree, Rope, lO, and Space. All 
these names are defmed in the environment, BTree 
explicitly and the others from Cedarlnterfaces through 
the LET clause, BTreelmpl also depends on Rope, lO jj 
and Space instances from Cearlnstances, as indicated in 
the second argument list. 

The interface parameters are used by the compiler for 
type-checking, and so that details about the types can be 
used to improve the quality of the object code. The ^ 
instance parameters are used by the loader and they 
specify how procedures EXPORTed by one module 
should be linked to other modules which IMPORT 
them. 

A. User Interface *' 

I. General 

The system modeller provides an interactive inter- 
face for ordinary incremental program development. 
When used interactively, the role of the modeller is 50 
similar to that of an incremental compiler; it tries to do 
as little work as it can as quickly as possible in order to 
produce a runnable system. To do this, it keeps track 
incrementally of as much information as possible about 
the objects in the active models under use. 55 

For example, consider the following Scenario. As- 
sume a model already exists, say BTree.model, and a 
user wants to change one module to fix a bug (code 
error). Earlier, the user has started the modeller with 
BTree.model as the current model. The user uses the 60 
system editor to make a change to BTreeImpl.cedar!(- 
Jan 14, 1983 14:44:09). When the user finishes editing 
the module and creates a new version BTreelmpl- 
.cedar!(Apr. 1, 1983, 9:22:12), the editor notifies the 
modeller by calling its Notice procedure, indicating the 65 
BTreeImpl.cedar!(Apr. 1, 1983, 9:22:12) has been pro- 
duced from BTreeImpl.cedar!(Jan. 14, 1983, 14:44:09). 
If the latter is referenced by the current model, the 



modeller notices the new version and updates BTree.- 
model!(Jan. 14, 1983, 14:44:11) to produce BTree.- 
model!(Apr. 1, 1983, 9:22:20), which refers to the new 
version. The user may edit and continue to change more 
files. When the user wants to make a runnable version of 
the system, upon command to the modeller, which then 
compiles everything in correct order and, if there are no 
errors, produces a binary file. 

A more complex scenario involves the parallel devel- 
opment of the same system by two programmers. Sup- 
pose both start with a system described by the model 
Mo, and end up with different models Mi and M2. They 
may wish to make a new version M3 which merges their 
changes. The modeller can provide help for this com- 
mon case as follows: If one programmer has added 
deleted or changed some object not changed by the 
other, the modeller will add, delete, or change that 
object in a merged model. If both programmers have 
changed the same object in different ways, the modeller 
cannot know which version to prefer and will either 
explore the changed objects recursively, or ask the user 
for help. 

More precisely, we have 

M3 = Merge[Base~Mo, Newi~Mi, Newi — Mj] 

and Merge traces out the three models depth-first. At 
each level, for a component named p: 



If 



Add to result 



Base.p=Ml.p=M2.p 
Base.p = Mj.p9tM2/l.p 
Base.p = Mj.p, no M2/l.p 
no Base.p or Mj.p 
Base.p9tMi.p^M2P, all models 
ELSE 



Base.p 

M2/1.P 

leave p out 

M2/1.P 

Merge{Base.p:,M i .p,M2.p] 

error, or ask what to do. 



At all points, the modeller maintains a model that 
describes the current program. When a user makes a 
decision to save a module or program, this is accom- 
plished by an accurate description in the model. Since 
the models are simply text files, the user always has the 
option of editing the model as preferred, so the modeller 
does not have to deal with specifically obscure special 
cases of editing. 

In a session which is part of the daily evolution of a 
program of software system, the user begins by creating 
an instance of the modeller, which provides a window 
on the user's screen, as shown in FIG. 20, in this case 
being that of the Cedar environment. The following 
explanation and subsequent sections to follow give an 
overview of its use, suggested by the contents of the 
Figure per se. 

The modeller window is divided into four fields, 
which are, from top to bottom: (1) A set of screen initi- 
ated names in field 30 that function as buttons to control 
the modeller, (2) A field 32 where object names may be 
typed, (3) A feedback field 34 for compiler progress 
messages, and (4) A feedback field 36 for modeller mes- 
sages. 

To aid in the explanation modeller, the following 
example follows the steps the user performs to use the 
modeller. These steps are illustrated in the flow diagram 
of FIG. 21. 

Step 1. Assume that the modeller instance has just 
been created. The user decides to make changes to the 
modules in Example.Model. The name of the model is 
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entered in the field 32 following the "ModelName:" 
prompt, and initiates the StartModel button in field 30. 
From this point on the modeller is bound to Example.- 
Model. StopModel in field 30 must be initiated before 
using this instance of the modeller on another model. 5 
StartModel initializes data structures in this instance of 
the modeller, StopModel frees the data. 

Step 2. The user makes changes to objects on the 
user's personal machine or computer. The system editor 
calls the modeller's Notice procedure to report that a 10 
new version of an object exists. If the object being ed- 
ited is in the model, the modeller updates its internal 
representation of the model to reflect the new version. 
If the changes involve adding or deleting parameters to 
modules, the modeller uses standard defaulting rules to 15 
modify the argument list for the object in the model. 

Step 3. Once the user has made the intended edits, the 
user initiates Begin in field 30, which (a) recompiles 
modules as necessary, (b) loads their object files into 
memory, and (c) forks a process that starts the user's 20 
program running. Modules need to be recompiled if the 
corresponding source files have been changed, or if any 
modules they depend on have been compiled. Should 
(a) or (b) encounter errors, the modeller does not pro- 
ceed to (c). 25 

Step 4. After testing the programs, the user may want 
to make changes simple enough that the old module 
may be replaced by the new module without re-loading 
and restarting the system. If so, after editing the mod- 
ules, the user initiates "Continue" in field 30, which tries 30 
to replace modules in the already loaded system. If this 
is successful, the user may proceed with the testing of 
the program and the new code wUl be used. If the mod- 
ule is not replaceable, the user must initiate "Begin" in 
field 30, which will unload all the old modules in this 35 
model and load in the new modules. 

Step 5. After completing desired changes, the user 
can initiate "StoreBack" in field 30 to store copies of his 
files on remote file servers, and then initiate "Unload" 
to unload the modules previously loaded, and finally 40 
initiate "StopModel" to free modeller data structures. 

The following is a more further explanation of some 
of the field 30 initiated functions. 

StartModel: The modeller begins by reading in the 
source text of a model and buiding an internal tree struc- 45 
ture traversed by subsequent phases. These phases use 
this tree to determine which modules must be compiled 
and loaded and in what order. Since parameters to files 
may have been defaulted, the modeller uses a database 
of information about the file to check its parameteriza- 50 
tion in the model and supply defaults, if necessary. If the 
database does not have an entry for the version of the 
file listed in the model, the modeller will read the file 
and analyze it, adding the parameterization information 
to the database for future reference. This database is 55 
described later. 

Notice Operation: The system editor notifies a mo- 
deller running on the machine when a new version of a 
file is created. The modeller searches its internal data 
structure for a reference to an earlier version of the file. 60 
If one is found, the modeller changes the internal data 
structure to refer to the new version. 

While making edits to modules, users often alter the 
parameterization of modules, i.e., the interface types 
and IMPORTed interface records. Since editing the 65 
model whenever this happens is time-consuming, the 
modeller automatically adjusts the parameterization, 
whenever possible, by using the defaulting rules of the 



modelling language: If a parameter is added and there is 
a variable with the same name and type as the new 
parameter, that variable is used for the actual parame- 
ter. If a parameter is removed, then the corresponding 
actual parameter is removed. The modeller re-parses 
the header of a "noticed" module to determine the 
parameters it takes. 

Some changes made by the user cannot be handled 
using these rules. For example, if the user changes a 
module so that it IMPORTs an interface record, and 
there is no interface record in the model with that name, 
the modeller cannot known which interface record was 
intended. Similarly, if the user changes the module to 
EXPORT a new interface record, the modeller cannot 
know what name to give the EXPORTed record in the 
model. In these situations, the user must edit the model 
by hand to add this information and start the modeller 
again on the new version of the model. 

Compilation and Loadmg: After the user initiates 
"Begin," the modeller uses the internal data structure as 
a description of a software system the user wants to run 
on the particular machine. To run the system, each 
module must have been compiled, then loaded and ini- 
tialized for execution. The modeller examines each 
module using the dependency graph implied by the 
internal data structure. Each module is compiled in 
correct compilation order if no suitable object file is 
available. Modules that take no parameters are exam- 
ined first, then modules that depend on modules already 
analyzed are examined for possible recompilation, and 
so on, until, if necessary, all modules are compiled. 
Modules are only recompiled if (1) the modules they 
depend on have been recompiled, or (2) they were com- 
piled with a different version of the compiler or differ- 
ent compiler switches than those specified in the model. 
If there are no errors, the modeller loads the modules by 
allocating memory for the global variables of each mod- 
ule and setting up links between modules by filling in 
the interface records declared in the module. When 
loading is completed, execution begins. 

StoreBack: Models refer to files stored on central file 
servers accessable by users on the distributed system. 
The user types a file name without file server or direc- 
tory information to the system editor, such as 
"BTreelmpl.Mesa," and the editor uses information 
supplied by the modeller to add location information 
(file server and directory) for the files. If the file name 
without location information is ambiguous, the user 
must give the entire file name to the editor. To avoid 
filling file servers with excess versions, the modeller 
does not store a new version of a source file on a file 
server after the source file is edited. Instead, the new 
versions are saved on the local disk. When the user 
initiates "StoreBack", all source files that have been 
edited are saved on designated remote directories. A 
new version of the model is written to its remote direc- 
tory, with references to the new versions of source files 
it mentions. 

The compiler may have produced new versions of 
object files for source files listed in the model. Each 
object file so produced is stored on the same directory 
as its corresponding source file. 

Multiple Instances of Modellers: More than one mo- 
deller may be in use on the same machine. The user can 
initiate the "NewModel" button to create another win- 
dow with the four subwindows or fields shown in FIG. 
20 and is used in the same manner. Two instances of a 
modeller can even model two versions of the same 
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system model. Since file names without locations are 
likely to be ambiguous in this case, the user will have to 
type file names and locations to the editor and do the 
same for the "ModelName:" field 32 in the modeller 
window. 5 

Other aspects of the operation of the modeller and 
modeller window in FIG. 20 is described in the follow- 
ing sections. 



II. Model Accelerators 



10 



Some models are shared among many users, who 
refer to them in their own models by using the ©-nota- 
tion and then using returned values from these shared 
models. An example is the model, "BasicCedar.Model," 
which returns a large number of commonly used inter- " 
faces (interface types) that a user might use. Although it 
is always possible to analyze all sub-models such as 
BasicCedar.Model, retrieving the files needed for analy- 
sis is very time consuming. 

When the user initiates "MakeModelBcd" in field 30, ^" 
the modeller makes an object file for a model, much as 
a compiler makes an object file for a source file. This 
model object file, called a .modelBcd file, is produced 
so that all parameters except interface records are given 
values, so it is a projection of the source file for the 
model and all non-interface record parameters. The 
.modelBcd file acts as an accelerator, since it is always 
possible to work from the sources to derive the same 
result as is encoded in the .modelBcd. 



III. Binding Functions 



30 



The loading ability of the modeller gives the user the 
ability to load the object files of any valid model. This 
speed of loading is proportional to the size of the system 35 
being loaded and the inter-module references. As the 
system gets larger, it takes more time to load. However, 
the Cedar Binder has the abihty to take the instructions 
and symbol table stored in each object file, merge these 
pieces of object, and produce an object file that contains 40 
all the information of the constituent modules while 
combining some tables used as runtime. This transfor- 
mation resolves references from one module' to another 
in the model, which reduces the time required to load 
the system and also saves space, both in the object file 45 
and when the modules are loaded. To speed loading of 
large systems, this feature has been preserved in the 
modeller. If "Bind" is initiated after "StartModel" and 
then "Compile" or "Begin" are initiated, an object file 
with instructions and symbol tables merged is pro- 50 
duced. 

The programmer may choose to produce a bound 
object file for a model instead of a .modelBcd file when 
(1) the model is very large and loading takes too long or 
the compression described above is effective in reduc- 55 
ing the size of the file or (2) the object file will be input 
to the program that makes the boot file for the system. 

IV. Module Replacement 

The ability to replace a module in an already loaded 60 
system can provide faster turnaround for small program 
changes. Module replacement in the Cedar type system 
is possible if the following conditions are met: 

(1). The existing global data of the module being 
replace may change in very restricted ways. Variables 65 
in the old global data must not change in position rela- 
tive to other variables in the same file. New variables 
can only be added after the existing data. If the order 



changed, outstanding pointers to that data saved by 
other modules might be invalidated. 

(2). Any procedures that were EXPORTed by the 
old version of the module must also be EXPORTed by 
the new version, since the address of these objects could 
have been passed to other modules, e.g., a procedure 
that is passed as a parameter. 

(3). There are a number of architectural restrictions, 
such as the number of indices in certain tables, that must 
be obeyed. 

(4). No procedures from the affected module can be 
executing or stopped as a breakpoint during the short 
period of time the replacement is occurring. 

The modeller can easily provide module replacement 
since it loaded the modules initially and invokes the 
compiler on modules that have been changed. When the 
user initiates "Continue" in the field, the modeller at- 
tempts to hasten the compUe-load-debug cycle by re- 
placing modules in the system, if possible. Successful 
module replacement preserves the state of the system in 
which the replacement is performed. 

The modeller calls the compiler through a procedural 
interface that returns a boolean true if rules (1) and (2) 
are obeyed; the modeller will also check to see that 
rules (3) and (4) are obeyed. If all four checks succeed, 
the modeller will change the runtime structures to use a 
new pointer to the instructions in the new module, 
which in effect replaces the old instructions by the new 
ones. 

Some changes are substantial enough to violate rules 
(l)-(4), so after edits to a set of modules, some modules 
are replaceable and others are not. When this happens, 
the modules that are replaceable are replaced by new 
versions. The modules for which replacement failed are 
left undisturbed, with the old instructions still loaded. If 
desire, the user may try to debug those changes that 
were made to modules that were replaceable. If not, the 
user can initiate the "Begin" button to unload the cur- 
rent version and reload the system. Since no extra com- 
pilations are required by this approach, the user will 
always try module replacement if there is a possibility 
that it will succeed and the user wants to preverse the 
current state of the program or software system. 

V. Debugger Interface 

When the Cedar debugger examines a stopped sys- 
tem, e.g., at a breakpoint, the debugger can follow the 
procedure call stack and fine the global variables for the 
module in which the procedure is declared. These 
global variables are stored in the global frame. The 
modeller can provide the debugger with module-level 
information about the model in which this module ap- 
pears, and provide file location and version information. 
This is particularly useful when the debugger wants to 
inspect the symbol table for a module, and the symbol 
table is stored in another file that is not on the local 
machine or computer disk or the user. 

The programmer/user deals with the model naturally 
while debugging the system. 

Since more than one modeller can be in use on a 
machine or computer, the modeller(s) call procedures in 
an independent runtime loader to add each model to a 
list of models maintained for the entire running system. 
When the modules of a model are loaded or unloaded, 
this list is updated, as appropriate. To simplify the de- 
sign, the list of models is represented by the internal 
data structures used by the modeller to describe a 
model. This model has no formal parameters and no file 
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where it is stored in text form, but it can be printed. This 
allows the debugger to use a simple notion of scope: a 
local frame is contained in the global frame of a module. 
This module is listed in a model, which may be part of 
another model that invokes it, and so on, until this top- 5 
most model is encountered. The debugger can easily 
enimierate the siblings in this containment tree. It can 
enumerate the procedures in a module, or all the other 
modules in this model, as appropriate. This type of 
enumeration occurs when the debugger tries to match 10 
the name of a module typted by the user against the set 
of modules that are loaded, e.g., to set the naming envi- 
ronment for expressions typed to the debugger. 

B. Data Structures and Tables (Caches) jj 

The procedures of the modeller can be categorized 
into these functional groups: 

1. Procedures to parse model source files and build an 
internal parse tree. 

2. Procedures to parse source and object files to de- 20 
termine needed parameterization. 

3. Procedures that maintain a table, called the projec- 
tion table, that expresses relationships between object 
files and source files, as described below. 

4. Procedures that maintain a table, called the file 25 
type table, that gives information about files described 

in models. This includes information about the parame- 
ters needed by the file, e.g., interface types, and infor- 
mation about its location on the file system. 

5. Procedures that load modules and maintain the 30 
top-level model used by the debugger. 

6. Procedures used to call the compiler, connect the 
modeller to the editor, and other utility procedures. 

7. Procedures to maintain version maps. 

The sections below discuss essential internal data 35 
structures used in these groups, illustrations of which 
are shown in the tables of FIGS. 18 and 19. 

I. Internal Parse Tree 

The model is read in from a text file and must be 40 
processed. The modeller parses the source text and 
builds an internal parse tree. This parse tree has leaves 
reserved for information that may be computed by the 
modeller when compiling or loading information. 
When a Notice operation is given to the modeller, it 45 
alters the internal data structures to refer to new ver- 
sions of files. Since new models are derived from old 
models when Notice operations occur, the modeller 
must be able to write a new copy of the model it is 
working on. 50 

There is one parse tree per source model file. The 
links between model files that are "called" by other 
model files are represented as pointers from one model's 
internal data structure to another in virtual memory. 

The internal data structure represents the depen- 55 
dency graph used to compile modules in correct compi- 
lation order by threading pointers from one file name to 
another in the parse tree. 

II. Model Independent Tables ^q 

It is impractical to repeat the entire procedure just 
described whenever any change is made to a system. 
Among other things, this would imply recompiling 
every module. Since the entire system is applicative, 
however, and the value of an object never changes, the 65 
results of any computation can be saved in a cache, and 
reused instead of repeating the computation. In particu- 
lar, the results of the type analysis of objects and the 



results of compilations can be saved. To this end, the 
modeller keeps three tables that record the results of 
computations that are too extensive to repeat. These 
tables serve as accelerators for the modeller and are 
stored as files on the local computer disk. 

These tables are of three types and are maintained 
independently from instances of the modeller on a local 
computer disk. 

The information in a table is like a cache for the mo- 
deller. It can be automatically reconstructed whenever 
it is not present, as the information is never purged. 
When the file containing the table becomes too large, 
the user simply deletes it from his local disk and the 
information is reconstructed. 

Object Type Table: This table contains a list of ob- 
jects that are referenced by models and have been ana- 
lyzed as to their types. An example is shown in FIG. 18. 
The modeller abstracts essential properties of the ob- 
jects in models and stores the information in this table. 
For example, a Cedar source file is listed along with the 
implied procedure type used by the modeller to compile 
and load it. The unique name of an object is the key in 
this table and its type is the value. The object type table 
also contains information that records whether a file has 
been edited, and if so, whether it has been saved on a 
remote file server. 

Projection Table: This table keeps a list of entries that 
describe the results of nmning the compiler or other 
programs that takes a source object file and any needed 
parameters, such as interfaces, and produces a binary 
object file. An example is shown in FIG. 18. Before 
invoking, for example, the compiler on a source file to 
produce an object file, the modeller consults this table 
to see if such a file is already available. The key in this 
table is all the information that affects the result: the 
name of the source object, the names of all the parame- 
ter objects, the compiler switches, and the compiler 
version. The value of a table entry is the name of the 
binary object that results. This name is constructed 
from user-sensible name of the source object, plus the 
version stamp, the 48-bit hash code of all the other 
information. An entry is added to the projection table 
whenever the compiler is successfully run. 

If an entry is not in the table, there may be an object 
file on the disk made by the compiler that predates the 
information in the projection table. If not, the compiler 
is invoked to produce the object file. In either case a 
new entry is added to the table for later use. 

It is possible for these tables to fill up with obsolete 
information. Since they are just caches and can always 
be reconstructed from the sources, or from information 
in the .modelBinary objects, they can be purged by any 
convenient method, including deleting them com- 
pletely. As information is needed again, it will be re- 
computed and reentered in the tables. 

The projection table is augmented by a different kind 
of cache provided by the file system. Whenever the 
result of a needed compilation is not found in the pro- 
jection table, the modeller constructs the 48-bit version 
stamp that the resulting binary object will have by hash- 
ing the source name and parameters, and searches for 
this object in the file system. If it is found, the compila- 
tion need not be redone. The result is put into the pro- 
jection table so that the file system need not be searched 
again. This search of the file system is suppressed for 
source files that have just been edited, since it would 
never succeed in this case. 
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The projection table does not include the location of jjj interaction Between Tables and .modelBcd files 
object files. Version maps, descnbed below, are used tor 

{yj_ As just indicated, .modelBcd file can be produced for 

Version Maps: The central file servers used by the a model that has been analyzed by initiating the 
system modeller can store more than one version of a 5 "MakeModelBcd" button. The .modelBcd file contains 
source file in a directory. An example is shown in FIG. *« ««!"« information descnbed m the previous tables. 
19. Each version is given a version number, which p^lv information relevant to the model bemg is ana- 
ranges from 1 to 32767 and is typically less than 100. ^/f^'^ ^/^ored The .mode Bed contams (a) a represen- 
„. *. . ^, .. ,. f i-, .1. ^o I--. tation of the internal parse tree that results from reading 
Obtaming the creation time of a source file or the 48-b.t ^^ ^^ ^^^ ^^^^^ ^.j^ ^^^ ^^^ ^^^^^ ^^ ^ ^^.^^ 

version stamp of object files from a central file server ^^^j^ ^^^ ^^^^ j.^^ referenced by the model, (c) 

takes between i and 1 second. For directories with ^ projection table describing the object files are are 

many versions of a file, searching for the create time or produced, for example, by the compiler, and (d) a ver- 

version stamp can take a few seconds per file. sjo^ m^p that describes, for each source and object file 

Since the modeller must determine the explicit ver- 15 ;„ q^^ ^^ (<,)^ ^ fjig location including a version number, 

sion number of the file that is referenced in the model, a model may refer to other models in the same way 

this slow search for large numbers of files referenced by it refers to other source files. The projection table in- 

models is prohibitively excessive. To avoid this exces- eludes references to .modelBcd files for these inner 

sive searching when it is running, the modeller uses an models. 

index between create times or version stamps and full 20 The information stored in the model-independent 

path names that include explicit version numbers for tables or present in .modelBcd files is used in four differ- 

files. Since the version numbers used by the file servers ent ways; three ways when the modeller is used, and 

are not unique and may be reused, the modeller uses this once by the release process, which is described later. 

index as a cache of hints that are checked when data in StartModel Analysis: Each application of a source 

the file is actually used. If there is no entry for a file in 25 file to a parameter list in the model is checked for accu- 

the cache, or if it is no longer valid, the versions of a file ""acy and to see if any parameters have been defaulted, 

are searched and an entry is added or updated if already Th^ ^^^io" information (create time) followmg the 

present. Commonly referenced files of the software ^°"''=«/''« Trf ^^1°^^ 'f '^^ ^f '^J^ P^'^^^ers 

•^ . • _ J • „• _, „„:„.„;„^ „„„t. needed by the file in the file type table. If no entry is 

system are inserted in a version map maintained on each ,„ ^ ' _, ^u j. . •* _, 

■' , . *^ 30 present, the source file must be parsed to get its parame- 

computer or macnine. ^ ^ , ters. The version map is used to obtain an explicit file on 

. In ^.nimary, the Object Type table speeds the analy- ^ jjj^ ^^^^ j,. ^j^^^^^ ^^ ^^ ^^^^^ ^^^ ^^^ „^^j^ ^^^ ^f 
sis of files, the Projection table speeds the translation of ,jjj^ jy^ j^ ^ ^^^^^^ ^^p ^, ve^ions ^f the source file 

objects mto denved objects, and Version Maps are used ^^ j^^ directory listed in the model are examined to see 

to avoid extensive directory searches. 35 if ^^^^y jjave the right create time. If so, an entry for that 

The modeller keeps its caches on each machine or version is added to the version map and the file is read 
computer. It is also desirable to include this kind of and its type is added to the object type table. If so such 
precomputed information with a stored model, since a version can be found by enumeration, an error is re- 
model is often moved from one computer or machine to ported in field 36. 

another, and some models are shared among many us- 40 If the version of the source file is given as "!H", mean- 

ers, who refer to them in their own models by using the ing the highest version on that directory, the directory 

©-notation. An example is the model Cedarlnterfaces.- is probed for the create time of the highest version, and 

model, which returns a large number of commonly used that create time is used as if it were given instead of 

interfaces that a program might need. Furthermore, "!H". 

even with the caches, it is still quite extensive to do all 45 FIG. 22 illustrates by flow diagram how a reference 

the typechecking for a sizable model. to "[Ivy] < Schmidt > X.Mesa" of July 25, 1 982 14:03 :02 

For these reasons, the modeller has the ability to 's treated by the StartModel analysis, 

create and read back compiled models. A compiled Compilation Analysis: After the user imtiates "Be- 

model contains 8'n" or "Compile" in field 30, the modeller constructs 

(1) a tree which represents a parsed and typechecked 50 object files for each source file in the model. Each 
version of the model source file and its parameters is looked up in the projec- 

,,, . • ^ ^ J ■ ^. ^ . , ..u * ■ f tion table. If not present, the modeller constructs the 

(2) object ype and projection tables with entnes for ^^ ^.^ ^^^^ ^^ J ^^^^ ;^ j.,^ ^^^^ ^^^ .^ i^ 

all the objects m the model; ^. , • ,», had been compiled from the source and parameters 

(3) a version map with entnes for all the objects in the ^^ ^^^^ ^^^ ^^^.^^ ^^p .^ ^^ ^^ ^^^ ^^^ ^ ^^^^^ 

'"^f' ■ , .,,.,. ,T, ^„ ,. file with this 48-bit version stamp. If not found in the 

When the user imtiates the MakeModelBcd button ^^^-^^ ^^^ ^^^ modeller searches for an object file in 

in field 30 of FIG. 20, the modeller makes this binary jj,g directory where the source file is stored. If found, an 

object for the current model, much as a compiler makes ^^j^y j^ ^^^^ to the version map and to the projection 
a binary file from a source file. In a .modelBcd object ^ table. 

any parameters of the model which are not instances ^he modeller does not search for object files corn- 
may be given specific argument values. This is much piled from source files that have just been edited since it 
like the binary objects produced by the compiler, in has knowledge that these have to be compiled, 
which the interface parameters are fixed. The .mo- if the modeller must compile a source file because it 
delBcd objects acts merely as an accelerator, since it is 65 cannot find an object file previously compiled, the 
always possible to work from the sources of the model source file is read using the version map entry for the 
and the objects it references, to derive the same result as source and an object file produced on the local com- 
is encoded in the .modelBcd. puter disk. Information about this object file is added to 
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the model-independent tales and version maps. The 
object file is stored on a file server later when "Store- 
Back" is initiated. The compilation analysis for this is 
illustrated in FIG. 23. 

Loader Analysis: Each object file must be read to 5 
copy the object instructions into memory. The modeller 
loader, as illustrated in the loading analysis of FIG. 24, 
looks up the 48-bit version stamp in the version map to 
find the explicit version of the file to read. 

Since the version maps are hints, the presence of an 10 
entry for a file in a version map does not guarantee that 
the file is actually present on the file server and, there- 
fore, each successful probe to the version map delays 
the discovery of a missing file. For example, the fact 
that a source file does not exist may not be discovered 15 
until the compilation phase, when the modeller tries to 
compile it. 

IV. Retention of Information in Tables 

When the modeller stores file type, projection, and 20 
version map information in .modelBcd files, it stores 
only information relevant to the model in use. When the 
modeller reads .modelBcd files, it takes the information 
from the .modelBcd and adds it to cache tables main- 
tained on each machine or computer. When a module is 25 
compiled for the first time, this information is added to 
the tables manage centrally on each computer. This 
information can, over time, become obsolete and re- 
quire large amounts of disk space, since these tables are 
stored in files on the local computer disk. If these files 30 
are deleted from the local disk, the modeller will recon- 



ter, who runs the modeller to verify that a proposed 
release is consistent and complete, and takes corrective 
action if it is not. Errors in models, such as references to 
non-existent files or references to the wrong versions of 
files, are detected by the Release procedure of the mo- 
deller. When errors are detected, the Release Master 
notifies appropriate implementor/user to correct the 
model. 

Releases can be frequent, since performing each re- 
lease imposes a low cost on the Release Master and on 
the environment programmers. The Release Master 
does not need to know any details about the packages 
being released, which is important when the software of 
the system becomes too large to be understood by any 
single programmer/user. The implementor/user of 
each package can continue to make changes until the 
release occurs, secure in the knowledge that the pack- 
age will be verified before the release completes. Many 
programmers make such changes at the last minute 
before the release. The release process supports a high 
degree of parallel activity by programmers engaged in 
software development. 

II. The Top Model 

The Release Master maintains a model with one com- 
ponent for each component of the release. This list, 
called the Top model, defines, for every model named 
in the list, a file server and directory where it can be 
found. While a release is being developed, this model 
refers to objects on their working directories, e.g., the 
top model might be 



Top~[ 

BTree ~ @(indigo]<Int>BTree.Model!H -ReleaseAs [Indigo] < Cedar >-. 

Runtime ~ @(Indigo]<Int>Runtime.Model!H -ReleaseAs [Indigo] < Cedar >- 



struct the information as it uses it. 

C. Releases 

40 
I. General 

As previously indicated. Release is a software system 
composed of a collection of modules which have been 
tested for conformance to some kind of specification, 
and filed so that any one of them can be retrieved sim- 45 
ply and reliably as long as the release remains active. 
The Release procedure in the modeller takes a model, 
performs various checks on its components, builds the 
system it describes, and moves the' system and all the 
components to designated directories. In more detail, 50 
Release [M]: 

(1) Checks that M and each comp>onent of M is legal: 
syntactically correct, type-correct, and causes no com- 
piler errors. 

(2) Ensures that all objects needed by any component 55 
of M are components of M, and that only one version of 
each object exists (unless multiple versions are explicitly 
specified). 

(3) Builds the system described by M. 

(4) Copies all the files representing objects in M to a 60 
place where they cannot be erroneously destroyed or 
modified. 

A release is complete if and only if every source file 
needed to compile every object file is among the files 
being released. A release is consistent if and only if only 65 
one version of each package is being released, and other 
packages depend only on that version. The release pro- 
cess is controlled by a person acting as a Release Mas- 



The Top model is used during the development phase 
as a description of models that will be in the release and 
gives the locations of these objects while they are being 
developed. The Top model provides the list of moldels 
that will be released. Models not mentioned in the Top 
model will not be released. 

Every model M being released must have a LET 
statement at the beginning that makes the components 
in the Top model accessible in M. Thereafter, M must 
use the names from Top to refer to other models. Thus, 
M must begin 

LET@[Indigo<Int>Top.Model!H IN [ 
RTypes: INTERFACE ~ Runtime, 



Clients of a release component, e.g., RTTypes, are 
not allowed to refer to its model by ©-reference, since 
there is no way to tell whether that model is part of the 
release. Aside from the initial reference to Top, a re- 
lease component may have ©-references only to sub- 
components of that component. 

A model M being released must also have a comment 
that gives its object name in the Top Model (e.g. 
BTree), and the working directory that has a copy of 
the model, e.g., 
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-ReleaseName BTree 



— WorkingModelOn [Indigo] < Int> BTree.Model 

These comments are redundant but allow a check that j 
Top and the component, and hence the Release Master 
and the implementor/user, agree about what is being 
released. 

M must also declare the release position of each file, 
by appending it as a comment ater the filename in the |q 
model, e.g., 

@[Ivy] < Work > Xlmpl.MesalH— ReleaseAs 
[Indigo] < Cedar> XPack > — □ 

A global ReleaseAs comment can define the default '5 
release position of files in the model (which may differ 
from the release p>osition of the model itself). Thus if the 
model contains a comment, 



— DefaultReleaseAs [Indigo] < Cedar > BTrees> - 

then the user may omit the 

—ReleaseAs (Indigo[<Cedar>BTrees>— 



20 



25 



clauses. 



D. Modeller Implementation 

The modeller must be able to analyze large collec- 
tions of modules quickly, and must provide interfaces to 30 
the compiler, loader, debugger, and other programs. 
Described first are the basic algorithms used for evalua- 
tion and then a description of the algorithms used for 
releases. The cache tables used have been previously 
explained which gently improve performance in the 35 
normal case of incremental changes to a large software 
system. 

I. Evaluation 

In order to build a program or system, the modeller 40 
must evaluate the model for the program. As previously 
explained, a model is an expression written in SML 
notation. Evaluating an SML expression is done in three 
steps: 

(1) The Standard /3-reduction evaluation algorithm of 45 
the typed lambda calculus converts the expression into 
one in which all the applications are of primitive ob- 
jects, namely system modules. Each such application 
corresponds to compilation or loading of a module. 
/3-reduction works by simply substituting each argu- 50 
ment for all occurrences of the corresponding parame- 
ter. SML operations such as selecting a named compo- 
nent of a binding are executed as part of this process. 
Thus, in the example, 

55 
LET Instances— @CedarInstances. model IN 
Instances-Rope 



evaluates to 



@[Indigo]<Cedar>RopeImpl.cedar!(July 10, 1982, 
17:10:24)[. ..][...] 
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where the arguments of RopelmpI are filled in accord- 
ing to the defaulting rules. 

(2) Each application of a .cedar object is evaluated by 65 
the compiler, using the interface arguments computed 
by (1). The result is a .binary or .Bed object. Of course, 
each interface argument must itself be evaluated first; 



i.e., the interfaces on which a module depends must be 
compiled before the module itself can be compiled. 

(3) Finally, each application of a .Bed object com- 
puted in (2) is evaluated by the loader, using the in- 
stance arguments computed by (1). Cedar permits mu- 
tual recursion between procedures in different modules, 
so it is not always possible to fully evaluate the instance 
arguments. Instead, for each instance of an interface, a 
record is allocated with space for all the components of 
the interface. A pointer to the record is passed as an 
argument, rather than the record itself Later, when the 
.binary object application which defines the interface 
has been evaluated by loading the object, the record is 
filled in with the results, namely the procedures and 
other values defined by that module. 

Once everything has been loaded, the result is a runn- 
able version of the program or software system. 

Step (1) is done when the user initiates the Start- 
Model screen button shown in FIG. 20 or on the af- 
fected subtree whenever the current model is modified 
by a Notice operation. For StartModel, the modeller 
reads the model from its source file, parses the source 
text and builds an internal parse tree. For Notice, the 
parse tree already exists, and is simply modified by 
substituting the new version for each occurrence of the 
old one. The leaves of this parse tree are the system 
modules referenced with "@" from the model. If an- 
other model is referenced, it does not become a leaf 
Instead, its parse tree is computed and becomes a sub- 
tree of the containing model. 

After the parse tree is buUt, it is evaluated to produce 
a value tree. The evaluation applies functions by substi- 
tuting arguments for parameters in the function body, 
looks up names in bindings, does type checking, and 
supplies defaulted arguments. The first two operations 
have already been discussed. Typechecking requires 
knowing the type of every value. For a value which is 
a system module, the modeller obtains its type by exam- 
ining the first few lines of the module, where the inter- 
faces and instances imported by the module are de- 
clared in DIRECTORY and IMPORTS clauses, to- 
gether with the instances EXPORTed in an EXPORTS 
clause. 

For example, a module M which uses interfaces A 
and B, IMPORTS an instance of A, and EXPORTS an 
instance of B, begins 

DIRECTORY A.B; .__ 

M: PROGRAM 
IMPORTS A: 
EXPORTS B; 

and has the type 

[INTERFACE A, INTEFACE B]—[[A]-»[B]] 

i.e., it is a function taking two interface arguments 
and returning, after it is compiled, another function that 
takes an instance of A and returns an instance of B. The 
modeller checks that the arguments supplied in the 
model have thee types, and defaults them if appropriate. 
SML typechecking is discussed in detail in the Article 
of B. W. Lampson et al, "Practical Use of a Polymor- 
phic Applicative Language", Proceedings of the lOtA 
Symposium on Principles of Programming Languages, 
Austin, Tex., January 1983. 
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After the entire model has been evaluated, the mo- 
deller has determined the type of each module and has 
checked to determine that every module obtains the 
arguments of the type it wants. Any syntactic or type 
errors discovered are reported to the user. If there are 5 
none, then whenever a value is defined in one module 
and used in another, the two modules agree on its type. 
Nothing at this point has yet been compiled or loaded. 

After step (1) , the value of the model is a tree with 
one application for each compilation or loading opera- 10 
tion that must be done. The compilation dependencies 
among the modules are expressed by the aguments: if 
module A is an argument to module B, then A must be 
compiled first, and if A changes, B must be recompiled. 
Because of the level of indirection in the implementa- 15 
tion of loading, it is not necessary to reload a module 
when other modules change. 

To get from this tree to a fuUy compiled program or 
system, each application of a source module must be 
evaluated by the compiler, as described in (2). During 20 
this evaluation, the compiler may find errors within the 
module. This step is done when the user initiates the 
"Compile" or "Begin" button. 

After step (2), the value of the model is a tree in 
which each application of a source object has been 25 
replaced by the binary object that the compiler pro- 
duced. To get from this tree to a runnable program or 
system, each binary object must be loaded, and each 
instance record filled in with the procedures EX- 
PORTed from the modules that implement it. The de- 30 
tails of how this is done are very dependent on the 
machine architecture and the runtime data structures of 
the implementing language. 

E. Release Utihty 35 

After preparation of all models that are to be re- 
leased, the Relase Master runs the Release Utility, Re- 
lease, which makes three passes over the module being 
released. 

40 
I. Phase one: Check 

The Check phase of Release checks the Top model 
and all its sub-models for problems that might prevent a 
successful release. Each model is parsed and all files 
listed in the model are checked. Check ensures that the 45 
versions listed in the models exist and that their parame- 
terization is correct. The directory containing each 
source file is checked to make sure it contains a valid 
object file. This guards against compilation errors in the 
source files. Common blunders are caught, such as a 50 
reference to a model that is not in the Top model. The 
Release Master contacts implementors and asks for 
correction of errors caught in this phase. 
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The Move phase moves the files of the release onto 
the release directory and makes new versions of the 
models that refer to files on the release directory instead 
of the working directory. For each model listed in the 
release position list. Move: 60 

(1) reads in the model from the working directory, 

(2) moves each file explicitly mentioned in the model 
to its release position, 

(3) writes a new version of the source file for the 
model in the release directory. 65 

This release version of the model is like the working 
version except that (a) all working directory paths are 
replaced by paths on the release directory, (b) a com- 



ment is added recording the working directory that 
contained the working version of the model, and (c) the 
LET statement referring to the Top model is changed 
to refer to the one on the release directory. 

For example, the model may look like the following: 



--ReleaseName BTreeModel 

--CameFromModelOn [Indigo] < Int > Btree.Model 
--DefaultCameFrom [Indigo] < Int > BTrees > 
LET @[ivy}<Rel>ReleasePosition.Model IN [ 

RTTypes: 

INTERFACE ~ @[Indigo]<Cedar>XPack>file.bed!1234 

-CameFrom [Indigo] < Int >XPack>-, 



Any references to highest version, "!H", are changed 
to be explicit create times as the model is written. 

At the end of phase Move, the working position 
model is automatically converted to a release position 
model that defines the same variables as the working 
position model, but sets those variables to refer to the 
model stored on the release directory. A release posi- 
tion model might be 



Position ~ [ 

BTreeModel ~ @[Indigo]<Cedar>BTree.Model!1234, 

RuntimeModel - @[Indigo]<Cedar>Runtime,Model!]2345] 



Note that the LET switch is a deviation from explicit 
parameterization that allows us to change the nature of 
each model from being a development version to being 
a released version. The LET switch could be avoided if 
every model took a parameter that controlled whether 
its LET statement should refer to the working position 
model or the release position model. The SML lan- 
guage could be augmented with a type "BOOLEAN" 
and an IF-THEN-ELSE expression to accomplish this. 
Because Release has to rewrite models anyway to elimi- 
nate "!H" references, the LET switch is chosen to be 
accomplished automatically. 

Phase Move also constructs a directed graph of mod- 
els in reverse dependency order that will be used in 
phase Build. In this dependency graph, if Model A 
refers to model B, then B has an edge to A. 

FIG. 22 illustrates the movement of files by this 
phase. 

III. Phase Three: Build 

The Build phase takes the dependency graph com- 
puted during the move phase and uses it to traverse all 
the models in the release. For each model: 

(1) All models on incoming edges must have been 
examined. 

(2) For every source file in the model, its object file is 
moved to the release directory from the working direc- 
tory. 

(3) A.modelBed file is made for the version on the 
release directory. 

(4) If a special comment in the model is given, a fully- 
bound object file is produced for the model, usually to 
use as a boot file. 

After this is done for every model, a version map of 
the entire release is stored on the release directory. 
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FIG. 23 illustrates the movement of files by this 
phase. 

At the conclusion of phases Check, Move and Build, 
Release has established that: 

(1) Check: All reachable objects exist, and derived 5 
objects for all but the top object have been com- 
puted. This means the files input to the release are 
statically correct. 

(2) Move: All objects are on the release directory. All 
references to files in these models are by explicit create 10 
time (for source files) or version stamps (for object 
files). 

(3) Build: The system has been built and is ready for 
execution. All desired accelerators are made, i.e., .mo- 
delBcd files and a version map for the entire release. 15 

IV. Phase Implementation Details 

Phase Check. In order to know the parameterization 
of files referenced in the model, some part of each sys- 
tem file must be read and parsed. Because of the large 20 
number of files involved, phase Check maintains object 
type and projection tables and a version map for all the 
files on their working directories. These tables are filled 
by extracting the files stored in the .modelBcd files for 
the models being submitted to the release. Any models 25 
without .modelBcd accelerators are read last in phase 
Check and the result of analyzing each file is entered 
into the database. The version map information about 
object file location(s) and projection table are used later 
in phase Build. 30 

Because files can be deleted by mistake after the .mo- 
delBcd file is made and before phase Check is run, Re- 
lease checks that every version of every file in the re- 
lease is present on the file server by verifying the file 
location hints from the .modelBcd files. 35 

Phases Move and Build. The Move and Build phases 
could have been combined into a single phase. Separat- 
ing them encourages the view that the BuUd phase is not 
logically necessary, since any programmer can build a 
running system using the source models and source files 40 
that are moved to the release directory during the Move 
phase. The Build phase makes a runnable system once 
for all users and stores the object files on the release 
directory. 

The Build phase could be done incrementally, as each 45 
model is used for the first time after a release. This 
would be useful when a release included models that 
have parameters that are unbound, which requires the 
user to build the model when the model is used and its 
parameter are given values. 50 

The Check phase file type and projection tables and 
version map are used to make production of the .mo- 
delBcd files faster. The projection table is used to com- 
pute the version stamps of object files needed, and the 
version map is used to get the file name of the object 55 
file. This object file is then copied to the release direc- 
tory. The file type entry, projection entry and new 
release position of source and object files are recorded 
in the .modelBcd being built for the released model. 

The Build phase has enough information to compile 60 
sources files if no suitable object files exist. To speed up 
releases, it is preferred that the programmer/user make 
valid object files before the operation of Move and 
Build. If such an object file is not on the same directory 
as the source file, the programmer/user is notified of his 65 
error and ask to prepare one. If the Release Master ran 
the compiler, he would most likely compile a file that 
the programmer had fogotten to recompile, and this file 



might have compilation errors in it. The ability to auto- 
matically compile every file during a release is useful in 
extensive bootstraps, however. For example, a conver- 
sion to a new instruction set, where every module in the 
release must be compiled, is easily completed using a 
cross-compiler during the phase Build. 

The Build phase produces the version map of the 
release by recording the create time or version stamp of 
every file stored by Release on the release directory, 
along with file server, directory, and version number 
for the file. The version maps supplied by the .mo- 
delBcd files that were submitted to the release cannot be 
used, since they refer to files on their development 
directories and not on the release directories. This re- 
leased version map is distributed to every machine or 
computer. Although the .modelBcd files also have this 
information, it is convenient to have allthe version in- 
formation released in one map. 

FIG. 24 is an example of a single version map. 

The working position model may list other nested 
working position models. The objects defined in the 
nested working position model are named by qualifying 
the name of the outer object. For example, if Top con- 
tained 



Top~[ 

NestedSet - @[Indigo]<Int>NestedWPM.Mcidel!H - ReleaseAs 
[Indigo] < Cedar > - 



] 



Then, the elements of the nested working position 
model can be referred to using "." notation, e.g., Top.- 
NestedSet.Element. The "ReleaseAs" clause in Top 
indicates the directory in which the analogous release 
position model is written. The same algorithm is used to 
translate the working model into a release model. 

4. Summary 

A model refers to objects, i.e. source files, binary 
(object) files or other models, by their unique names. In 
order to build a system from a model, however, the 
modeller must obtain the representations of the objects. 
Since objects are represented by files, the modeller must 
be able to deal with files. There are two aspects to this: 

(1) Locating the file which represents an object, start- 
ing from the object's name. 

(2) Deciding where in the file system a file should 
reside, and when it is no longer needed and can be 
deleted. 

It would be desirable if an object name could simply 
be used as a file system name. Unfortunately, file sys- 
tems do not provide the properties of uniqueness and 
immutability that object names and objects must have. 
Furthermore, most file systems require a file name to 
include information about the machine or computer that 
physically stores the file. Hence, a mapping is required 
from object names to the full pathnames that unambigu- 
ously locate files in the file system. 

To locate a file, the modeller uses a location hint in 
the model. The object reference @[Ivy]< Schmidt >B- 
TreeImpl.cedar!(Jan. 14, 1983, 14:44:09) contains such a 
hint, [Ivy] < Schmidt >. To find the file, the modeller 
looks on the file server Ivy in the directory Schmidt for 
a file named BTreelmpl.cedar. There may be one or 
more versions of this file; they are enumerated, looking 
for one with a creation date of Jan. 14, 1983, 14:44:09. If 
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such a file is found, it must be the representation of this 
object. 

The distributed environment introduces two types of 
delays in access to objects represented by files: (1) If the 
file is on a remote machine, it has to be found. (2) Once 5 
found, it has to be retrieved. 

Since retrieval time is determined by the speed of file 
transfer across the network and the load on the file 
server, the modeller tries to avoid retrieving files when 
the information it wants about a file can be computed 10 
once and stored in a database. For example, the type of 
an object, which is the information needed to compute 
its compilation dependencies, is small compared to the 
object itself The object type table stores the types of all 
objects of current interest; a source object in the table 15 
does not have to be examined, or even retrieved, unless 
it actually needs to be recompiled. 

In cases where the file must be retrieved, determining 
which machine or computer and directory has a copy of 
the version desired can be very time consuming. Even 20 
when a file location hint is present and correct, it may 
still be necessary to determine several versions of the 
file to find the one with the right creation date. The 
modeller minimizes these problems by keeping another 
cache, which maps an object name into the full path 23 
name in the distributed file system of a file which repre- 
sents the object. This cache is the Version Map, dis- 
cussed previously. Note that both source objects, whose 
unique identifiers are creation dates, and binary objects, 
whose unique identifiers are version stamps, appear in 30 
the version map. The full pathname includes the version 
number of the file, which is the number after the "!". 
This version number makes the file name unique in the 
file system so that a single reference is sufficient to 
obtain the file. 3S 

Thus, the modeller's strategy for minimizing the cost 
of referencing objects has three paths: 

(1) Consult the object type table or the projection 
table, in the hope that the information needed about the 
object is recorded there. If it is, the object need not be 40 
referenced at all. 

(2) Next, consult the version map. If the object is 
there, a single reference to the file system is usually 
sufficient to obtain it. 

(3) If there is no entry for the object in the version 45 
map, or if there is an entry but the file it mentions does 
not exist, or does not actually represent the object, then 
use the file location hint to identify a directory, and 
enumerate all the versions of the file to fmd one which 
does represent the object. If this search is successful, 50 
make a new entry in the version map so that the search 
need not be repeated. 

Like the other caches, a version map is maintained on 
each computer or machine and in each .modelBcd ob- 
ject. A .modelBcd version map has an entry for each 55 
object mentioned in the model. A machine version map 
has an entry for each object which has been referenced 
recently on that machine. In addition, commonly refer- 
enced objects of the software system are added to the 
machine version map as part of each release. 60 

Since the version maps are hints, a version map entry 
for an object does not guarantee that the file is actually 
present on the file server. Therefore, each successful 
probe to the version map delays the discovery of a 
missing file. For example, the fact that source file does 65 
not exist may not be discovered until the compilation 
phase, when the modeller tries to compile it. This means 
that the modeller must be robust in the face of such 



errors. The release process, however, guarantees that 
the files are present as long as the release remains active. 

While the system modeller has been described in 
conjunction with specific embodiments, it is evident 
that alternatives, modifications and variations will be 
apparent to those skilled in this art' in light of the forego- 
ing description. Accordingly, it is intended to embrace 
all such alternatives, modifications and variations as fall 
within the spirit and scope of the appended claims. 

What is claimed is: 

1. A software version management system for auto- 
matically collecting and recompiling updated versions 
of component software objects comprising a software 
program for operation on a plurality of personal com- 
puters coupled together in a distributed software envi- 
ronment via a local area network and wherein said 
objects include the source and binary files for various of 
said software program and are stored in various differ- 
ent local and remote storage means through said envi- 
ronment, said component software objects being peri- 
odically updated via environment editing means by 
various users at said personal computers and stored in 
designated storage means, said system including: 

models comprising system objects, 

each of said models representative of the source ver- 
sions of a particular component software object, 

each of said models containing object pointers includ- 
ing a unique name of the object, a unique identifier 
descriptive of the cronological updating of its cur- 
rent version, information as to an object's depen- 
dencies on other objects and a pathname represen- 
tative of the residence storage means of the object, 

means in said editing means to notify said manage- 
ment system when any one of said objects is being 
edited by a user, 

means in said management system in response to noti- 
fication of object editing to track said edited ob- 
jects and alter their respective models to the cur- 
rent version thereof, 

said management system upon command adapted to 
relieve and recompile said source files correspond- 
ing to said altered models and load the binary files 
of said altered component software objects and 
their dependent objects into said computers. 

2. The software version management system of claim 

1 wherein said system includes accelerator means to 
cache said object pointers in said models that never 
change to thereby avoid further retrieving of said ob- 
jects to parse and to discern said object pointers. 

3. The software version management system of claim 

2 wherein said accelerator means for said models in- 
cludes 

an object type table for caching the unique name of 
the object and its object type to enhance the analy- 
sis of a model by said management system, 

a projection table for caching the unique name of the 
source object, names of object parameters, com- 
piler switches and compiler version to enhance the 
translation of objects into derived objects, and 

a version map for caching said pathname. 

4. A method for automatically collecting updated 
versions of component software modules together 
which comprise a software program operative on a 
plurality of computers, said computers coupled to- 
gether in a distributed software environment via a local 
area network and wherein said modules are stored in 
various different local and remote storage means 
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throughout said environment and comprising the steps 

of 
creating models representative of said modules, each 
of said models containing object pointers compris- 
ing a unique name of the module, a unique identi- 
fier descriptive of the chronological updating of its 
current version, information as to a module's de- 
pendencies on other modules in the software pro- 
gram and a pathname representative of the resi- 
dence storage means where the module resides, 15 
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monitoring the editor faciUties of said computers to 
determine when a module is being edited to form 
an updated version thereof, 

altering the model to reflect said updated version 
upon completion of editing. 

5. The method of claim 4 which includes the steps of 
retrieving and recompiling said modules correspond- 
ing to the models altered, and 

loading the recompiled modules and their dependent 
modules into said computers. 

6. The method of claim 4 which includes the step of 
caching model object pointers that do not change to 
avoid discerning and parsing of said object pointers 
each time a model is altered. 
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